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(57) Abstract 

A system and method for conducting commerce over a distributed network (108) to manage merchant and product information in an 
electronic shopping basket (148), payment source information in an electronic wallet (140), and shipping address information in an electronic 
address book (142), all of such information being stored on a consumer computer (102). A commerce client running on the consumer 
computer is configured as a MIME handler and extaids the functionality of a standard Web browser to support computer based shopping. 
A merchant site Web server provides HTMl^oded Web documents which describe merchant products and which host computer-based 
shopping options. The HTML-coded Web documents contain flmction-calling information by which consumer selected options invoke 
shopping related functions on either the merchant (server) computer (104) or the consumer (client) computer (102). 
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Field of the Invention 

This invention relates to distributed computef networks such as the Internet. More particularly, this 
invention relates to client-server software components for ellowing consumers to purchase goods and services from 
merchants over a distributed network. 
Description of the Related Art 

Electronk: shopping systems currently exist which eliow users to remotely purchase goods and services from 
a variety of different on-line merchants over a distributed computer network such as the Internet. With systems of 
this type, the on-line merchants typically publish on-ine catalogs which can be viewed mteractively by the end users 
of the network usmg a personal computer. These catahigs include pictures, textual descriptions, and pricing 
information with respect to the products and/or services of the respective merchants, and typically include on-Gne 
forms for allowing users to return purchase orders to the merchants over the network. In WorU Wide Web ('Web') 
based implementations, the on-lme catalogs are in the form of hypertext documents which are hosted by the Web 
sites of the respecthre merchants, and the catalogs are accessed using a standard Web browser application which 
runs on the user computer. (A Web site is an Interoet-connected computer or computer system which runs server 
software for serving information using the standard protocols of the World Wide Web.) In other implementations, 
the on-line catalogs may, for example, be hosted by a centraized computer of an on-fine services network, such as 
MSN, or by an Internet site which b accessed using a proprietary client application (such as the client application 
of eShop Inc.). 

Some computer-based shopping systems currently exist which alhiw the user to selectively store product 
information (and various other types of 'shopping-state' informat'ion) for subsequent recall and use. This allows the 
user to rapidly bring up the information viewed during previous visits to the merchant site, and to essentially continue 
the shopping session where the user left off. Unfortunately, these systems generally store the product information 
on the server side only (e.g., on the merchant Web site), and do not include the necessary client and server software 
components for allowing the user to selectively store the product information on the consumer computer. This 
deficiency in the software architectures of existing computer-based shopping systems imposes several limitations on 
consumers. First, it makes it difficult for the consumer to gather product information from multiple merchants into 
a common, local storage area. This, hi turn, makes comparison shoppmg very difficult: the consumer generally 
cannot, without considerable inconven'nnce, compare like products (or services) from different on-line merchants. 
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Second, because the information is typically retained by the merchant site for a bnited period of time (typically a 
few days), the consumer is under a time constramt to make use of the stored product mformation. Moreover, many 
hundreds or thousands of requests by consumers to store product information on a merchant's site may degrade the 
merchant site's response time, and create other problems related to the heavy storage burden. 

5 Also, because existing computer-based shoppmg systems typically host most or all transaction options on 

the server side, the shopping experience often differs from merchant site to merchant site. Specifically, as the 
consumer moves from one merchant site to the next the options presented to the consumer and the steps required 
to navqate and effecthrety use those options often differ significantly. Thus, to browse product information and 
purchase products and/or servnes offered by multiple merchants, consumers often must adapt to and learn the 

10 options offered by each merchant site. 

Another problem with existing computer-based shopping systems is that they often require user entry of 
purchase information and shipping information upon every purchase, or at least require consumers to identify 
themsehres durmg each shopping session. These restrictions are time consuming, tedious, and bothersome. Further, 
repeated entry of payment information or shipping information increases the Ikelihood that a consumer win mistakenly 

15 enter incorrect information. 

The present invention addresses these and other problems with existing electronic shopping systems. In 
accordance with the mvention, an electronic shopping system is provMed which makes use of the existing client and 
server software components and protocols of the WorU Wide Web. and which adds various cfient-side functionality 
for allowing users to store, view, and process product Information (gathered from merchant Web sites), payment 

20 information, and shippmg information on the user computer. The system includes a speciaGzed cliem application 
(referred to as the 'commerce client') which runs on the consumer computer in conjunction with a standard Web 
browser. The cmnmerce client communicates with a speciaBzed commerce server (which runs on the merchant Web 
site in conjunction with a Web server) using a bi-directional function callhg protocol. Hypertext (HTML) catalog pages 
served by the merchant Web site, as well as 'user interface' hypertext documents stored on the user computer, 

25 include embedded function caDs which can be selectively invoked by the consumer whHe viewing the hypertext pages 
with the Web browser. Using these embedded function calls, the user can perform actions such as: request pricing 
or inventory information on a particular product from the merchant Web site; selectively store product information 
within a cGent-side shoppmg basket' view the contents of the shopping basket; and transmit encrypted shipping 
and/or payment information (stored on the consumer computer) to the merchant Web site. 

30 In accordance with one aspect of the invention, there is thus provided a method for gathering and 

comparing product information over a distributed network. Hie method comprises the steps of |a) sending a first 
hypertext document over the distributed network to a user computer, the first hypertext document comprising a 
description of (i) a first product (ii) 3 selectable product gathering option, and (iii) function-calling information 
associated with the product gatheroig option; (b) displaying the first hypertext document to a user via the user 

35 computer and monitoring user input for selection of the product gathering option; and (c) responding to selection of 
the product gathering option by calBng an executable function specified by the function-calGng information, the 
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f unction storing the description of the first product to a data storage area accessible to the user computer. Another 
embodiment of this aspect preferably comprises the further steps: (d) sending a second hypertext document over the 
distributed network to the user computer, the second hypertext document comprising (i) a description of a second 
product, (ii) a selectable product gathering option, and (iii) function-calling information associated with the product 
gathering option; (e) displaying the second hypertext document to the user via the user computer and monitoring user 
input for selection of the product gathering option; (f) responding to selection of the product gathering option by 
calling a second executable function represented in the function-calling information, the function storing the 
description of the second product to the data storage area; (g) displaying a product comparison option to the user 
via the user computer and monitoring user input for selection of the product comparison option; and (h) responding 
to selection of the product comparison option by retrieving from the local storage area the description of the first 
product and the description of the second product, and by f ormattmg the descriptions and displaying the descriptions 
to the user via the user computer. 

Another aspect of the present invention is a method for using a Web browser to manage local data. The 
local data is stored on a computer storage medium accessible to the user computer. The method comprises the steps 
of: (a) receiving with the Web browser an HTML document (HyperText Markup Language) comprising a user-selectable 
view option and funct'nn-caDmg information associated with the view option; (b) displaying the HTML document to 
a user via the user computer, the display faichiding the view option; (c) monitoring user input for selection of the view 
option; and (d) responding to selection of the view option by calling a function represented in the function-calling 
information, the function accessing and formatting the local data and displaying the local data to the user. 
Brief Descrintinn of the Drawinns 

These and other features of the invention are described below with reference to the drawings of a preferred 
embodiment of a computer-based shopping system, which is intended to illustrate end not to limit the invention, and 
bi which: 

Figure 1 iUustretes a consumer computer communicating with two merchant Web sites of the system in 
accordance with the present invention; 

Figure 2 illustrates a prefenred protocol for transferring function call requests and responses between the 
consumer computer and a merchant Web site of the system using the HTTP message stream between a standard 
Web browser and a Web server; 

Figure 3 illustrates a preferred software architecture for the merchant Web sites of the system; 

Figure 4 illustrates a preferred software architecture for the consumer computers of the system; 

Figure 5 illustrates data structures accessed and manipulated by shoppmg basket, wallet, and address book 
objects on the consumer computer; 

Figure 6 illustrates the steps performed in adding faiforniation (served by a merchant Web site) about a 
product to the shopping basket object: 
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Figure 7 illustrates the steps performed in viewing product infonnatlon stored within the shopping basket; 

Figure 8 illustrates the steps performed in deleting a product from the shopping basket; 

Figure 9 illustrates steps performed in viewing details about a product from the electronic shopping 

basket; 

Figure 10 illustrates the steps performed in viewing and manipulating payment source data in the wallet 
object on the consumer computer; 

Figure 11 ilhjstrates the steps performed in viewing and manipulating shipping address data in the address 
book object on the consumer computer; and 

Figure 12 illustrates the steps performed in purchasing selected products from merchant Web sites of the 
system over a distributed network. 

DataBed Dascrintio n of the Preferred Embodiment 

The present mventnin concerns electronic shopping and provides the ability to use a personal computer to 
compare and purchase products offered for sale via a distributed network. The invention is embodied within a 
computer-based shoppmg system which utiOzes the existing protocols and components of the World Wide Web. The 
computer-based shopping system is described in detail herein. 

In the preferred embodiment, the system includes a 'commerce client' process which runs on s consumer's 
computer in conjunction with a standard Web browser. The commerce client communicates over the Internet with 
a 'commerce server' (using a bHiirectional function calling protocol) executing on e merchant Web site. In a preferred 
embodiment, the commerce client inchides functionality similar to that of a shopping basket, a wallet and an address 
book, and the commerce server inchides functnnality for providing a variety of commerce-related services (such as 
accessing or returning product inf ormatnn, calculating taxes, processing orders, etc.). 

The commerce client and commerce server operate together to allow a consumer to gather product 
faiformation from any number of merchants whie the consumer's computer is connected to the Internet. The 
commerce client also permits the consumer to perform comparison shopping by reviewing product information 
gathered from varnus merchants. This product comparbon can be performed by the consumer at any time (e.g., whDe 
off-Bne) and over any length of time, regardless of whether the consumer's computer is connected to the Internet. 

A user unfamiliar wKh the operation of a computer-based shopping system which embodies the present 
invention can access instructional information (or application help) by selecting a help option. The instructional 
information is stored on one or more HTML-coded Web documents whteh are retrieved and displayed according to 
the user's needs. 

A computer-based shopping system embodying the present invention permits a user to purchase products 
from an on line merchant. The consumer uses the commerce client to authorize payment, select a payment source, 
select a shipping address (none of whnh require network connection) and also to place an order to the merchant 
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for the selected product. A network connection is established for the commerce client to communicate the order 
to the connnerce server. The payment and shipping information is protected from third party discovery using 



The following sections and subsections describe the invention in more Aetat 

A. Glossary of Terms and Acronyms 

B. Example Compiiter-Based Shopping Session 

C. Communication Between Commerce Client and Commerce Server 

D. Software Architecture of Merchant Web Site 

E. Software Architecture of Consunm' Conqiiiter 
Glossary of Terms and Acronyms 

The following terms and acronyms are used throughout the detailed description: 
Internet A collection of interconnected (public and/or prwate) networks that are linked together by a set 
of standard protocols (such as TCP/IP and HTTP) to form a global, distributed network. (While this term 
is intended to refer to what is now commonly known as the Internet, it is also intended to encompass 
variations which may be made 'm the future, including changes and additions to existing standard protocols.) 



World Wide Web TWeb"). Used herein to refer generally to both (i) a distributed collection of interlinked, 
user-viewable hypertext documents (commonly referred to as "Web documents" or 'Web pages') that are 

20 accessible, via the Internet, and (ii) the client and server software components which provide user access 

to such documents using standardized Internet protocols. Currently, the primary standard protocol for 
allowing applications to locate and acquire Web documents is HTTP (discussed behiw), and the Web pages 
are encoded using HTML (also discussed betow). However, the terms "Web" and 'World Wide Web' ere 
intended to encompass future markup languages and transport protocols which may be used in place of (or 

25 in additnn to) HTML and HHP. 

Client-Server. A model of interaction in a distributed system in which a program at one site sends a 
request to a program at another site and waits for a response. The requesting program is called the 
'cBent," and the program which responds to the request is called the "server.' In the context of the World 
30 Wide Web, the client is a °Web browser" (or simply "browser") which runs on e computer of a user; the 

program which responds to browser requests by serving Web pages is commonly referred to as a "Web 
server." 

TCPIIP (Transmission Control PratocolflntBrnet Protocol). A standard Internet protocol (or set of 
35 protocols) which specifies how two computers exchange data over the Internet. TCP/IP handles issues such 

as packetization, packet address'mg, handshaking and error correctnn. For more information on TCP/IP, see 



Volumes I, II and III of Comer and Stevens, Internetworkino with TCP/IP. Prentice Hall, Inc., ISBNs 0-1 3- 
468505-9 (vol. I), 0-13-1255274 (vol. II), and 0-13474222-2 (vol. Hi). 

HTML (HyperText Markup Language). A standard coding convention and set of codes for attaching 
5 presentation and linking attributes to informational content within documents. (HTML 2.0 is currently the 

primary standard used for generating Web documents.) During a document authoring stage, the HTML 
codes (referred to as "tags") are embedded within the infoimational content of the document. When the 
Web document (or 'HTML document") is subsequently transferred from a Web server to a browser, the 
codes are interpreted by the browser and used to parse and display the document. In addition to specifying 
10 how the Web browser is to display the document, HTML tags can be used to create links to other Web 

documents (commonly referred to as "hyperlinks"). For more information on HTML, see Ian S. Graham, Jhe 
HTML Source Book. John Wiley and Sons. Inc., 1995 (ISBN 0471-118944). 

Port or Port Mumber. (Also referred to as 'socket number.") In the context of the internet, a numerical 
15 identifier (norniaUv provided in conjunction with an IP address) whnh is used by TCP/IP to direct incoming 

data to a particular appGcation. Certain ports have been reserved by the Internet Assigned Number 
Authority (lANA) for certabi applications. For example, port 80 is reserved for HTTP, end is used on Web 
sites to direct incoming traffic to a Web server. (See 'URL" below.) 

20 URL (Uniform Resourco Locator). A unique address which fully specifBS the location of a file or other 

resource on the Internet. The general format of a URL is protocotZ/macbine address:port/path/filename. 
The port specification is optional and if none is entered by the user, the browser defaults to the standard 
port for whatever service is specified es the protocoL For example, if HTTP is specified as the protocoL 
the browser will use the HTTP default port of 80. 

25 

HTTP (Hypertext Transport ProtocoD. The standard World Wide Web client-server protocol used for the 
exchange of infonnation (such as HTML documents, and client requests for such documents) between a 
browser and a Web server. HTTP mchides a number of different types of messages which can be sent 
from the client to the server to request different types of server actnns. For example, a "GET" message, 
30 which has the format GET <URL>, causes the server to return the document or file located at the 

specified URL. 



35 



HTTP POST. A type of HTTP message which is used to request that the Web server accept information 
from the Web client. This information may, fer example, be in the form of a message to be posted to a 
newsgroup, or s database sidimission which is executed by a CGI scrqit. (See "CGI" below.) 
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MIME (Multipurpose Internat Multimedia Extensions) Type. A file extension or attachment which 
specifies the type or format of the file {e.g., HTML, text, graphics, audio, etc.). MIME typing allows the 
Web browser to determine how to process a file that is received from a Web server. For example, a file 
of MIME type HTML (extension ".htm' or ".html") will be displayed by the browser, while a file of MIME 
5 type X-WAV (extension ".wav") wifl typically be passed to an audio player which can handle the Microsoft 

WAV format. Standard Web browsers come pro-configured to handle popular MIME types. In addition, 
standard Web browsers can easily be configured by the user to handle new MIME types; this typically 
involves specifying the file extension of each new MIME type, and specifying the path and filename of the 
application (referred to as a "MIME handler") to which f 9es of such type should be passed. 



Internet Firewall. A security system placed between the Internet and an organization's network (such 
es a LAN) to provide a barrier against security attacks. Internet firewalls typically operate by monitoring 
incoming and/or outgoing traffic to/from the organization's network, and by allowing only certain types of 
messages to pass. For example, a firewall may be configured to albw the passage of all TCP/IP traffic 
addressed to port 80, and to block all other traffic. For more informatkin of htemet Firewalls, see 
Chapman and Zwicky, Buildmo Internet Fireways. O'ReBly publishing, 1995 (ISBN 1-56592-1 24-0). 

CGi (Comnon Gatsway Interface). A standard faiterface which specifies how a Web server (or possibly 
another informatnn server) launches and intaracts with external programs (such as a database search 
engine) in response to requests from clients. With CGI, the Web server can serve biformation which is 
stored in a format that is not readable by the cGent. and present such information in the form of a client- 
readable Web pege. A CGI program (called a "CGI script") may be invoked, for exemple, when e Web user 
fills out an on-screen form which specifies a database query. One disadvantage of CGI is that it generally 
requbes the launchbig of a separate process for each client request received. For more biformation on CGI, 
see Ian S. Graham, The HTML Souree Book. John Wihiy and Sons, bic, 1995 (ISBN 0471-118944), pp. 
231-278. 



ISAPI (Internet Server Application Program Interface). Microsoft's interface for allowing a Web server 
(or other information server) to launch and interact with external programs in response to requests from 
30 clients. ISAPI programs are in the form of dynamic link libraries (DLLs) which run in the same process 

space as the Web server. Thus, ISAPI performs a similar function to that of CGL but without requiring 
the launching of a separate process. Documentation on ISAPI is available from Microsoft Corporation as 
part of the Microsoft Internet Information Server Software Devehipment kit. 



35 B. Examnle Compiiter-Based Shenninn Session 



W09»21679 PCT/US97/20624 
-8- 

This section provides an illustration of a hypothetical computer-based shopping session wherein features 
of the present invention are used. Figure 1 illustrates a consumer computer 102, a first merchant site ("merchant 
site A") 104, and a second merchant site Cmerchant site B") 106, each connected to the Internet and utilizing the 
World Wide Web ("WWW") 108. Merchant site A 104 and merchant site B 106 host shopping-oriented transactions 
5 to advertise and sell products over the Internet. The consumer computer 102 and merchant Web sites 104, 106 
run client and server software applications which allow a consumer to browse product information advertised over 
the WWW, gather information about products and merchants, selecthrely store the product and merchant information 
in a client side database, compare product information from different merchants, and purchase products sold over 
the Internet. 

10 The consumer computer 102 comprises a processing unit 110, a data storage area 112, as wel as a 

monitor 114. keyboard 116, and a mouse 118. A standard Web browser 120 (such as, for example, Microsoft 
Internet Exptorar 2.0 or Netscape Navigator 2.0) and a speciaBzed commerce client process 122 execute on the 
processing unit 110. 

Merchant site A 104 comprises a processing unit 124 and a data storage area 128. A standard Web server 

15 128 (such as Microsoft Internet Information Server 1.0) and a specialized commerce server 130 execute on the 
processing unit 124. Likewise, merchant site B comprises a processing unit 132 and a data storage area 134. A 
standard Web browser 136 executes on the processing unit 132, as does a specialized commerce server 138. 

A consumer using the consumer computer 102 stores payment source information 140 such as a credit card 
number, expiration date, and issuing bank to the storage area 112. The consumer supplies a password in association 

20 wKh the payment source infonnation. The password is used not only to prevent future unauthorized accesses, but 
also to encrypt the payment source information. The payment source information represents preferred sources of 
cash and/or credit for purchasing products and/or services. The commerce client 122 writes encrypted payment 
source data to the data storage area 112. After entering the payment source mformation once and verifying its 
accuracy, the information persists on the consumer computer 102 without requving re-entry by the consumer. The 

25 consumer designates one of the payment sources stored as the preferred payment source. 

The consumer also stores shippnig address information 142 to the storage area 112 va the consumer 
computer 102. Shipping address informatkm mdicates preferred destinations for delivery of products and includes, 
for example, a personal resklence address, a P.O. Box. or a business address. Again, the commerce client 122 writes 
shippmg address information 142 entered by the consumer to the storage area 112. After the preferred shipping 

30 destbiatKins are entered, they need not be entered a second time. As done with the payment source data, the 
consumer designates one shipping address as the preferred shipping address. 

A consumer uses the consumer computer 102 to shop for products such as, for example, an audio compact 
disc, a downloadable software program, a rare coin, or a refrigerator, offered by merchants via the Worid Wide Web 
108. Using the example of shopping for a refrigerator, the consumer uses the consumer computer 102 to establish 

35 a connection to the Internet and uses a Web browser to navigate World Wide Web 108 ates. Connecting to the 
Internet and browsing the WWW is weD known and the steps invohred wiD not be further described. 
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The consumer uses the Web browser 120 to access a merchant site A 104 on the WWW. The Web server 
128 of merchant site A 104 responds to the access initiated by the consumer computer 102 by retrieving a first 
HTML document |i.e., a collection of data encoded in compliance with the Hyper-Text Markup Language) from the 
set of HTML documents 144, and by then transmitting the first HTML document to the Web browser 120 of the 
5 consumer computer 102. 

The Web browser 120 interprets the HTML document and creates on the monitor 114 a page-oriented 
representation of the document. The consumer views the document on the monitor 114. The document may, for 
example, present textual information to the consumer describmg merchant site A 104 such as the nature of products 
offered and the forms of payment accepted in fillmg orders for the products. The consumer may, for example, 
10 discover that merchant site A offers refrigerators for sale and accepts VISA for payment. 

Generally, consumer-selectable options ("hypertext links') are also presented within the HTML document 
which, if selected by a consumer using the mouse 118 or the keyboard 116, cause the consumer computer 102 to 
transmit requests to the Web server 128 to retrieve and transmit additional HTML documents providing related or 
more detailed Information. The consumer navigates additional hypertext links and browses additional HTML 
15 documents summarizing features of refrigerators sold by merchant site A. 

The consumer decides that one of the refrigerators offered by merchant site A is well-suited to the 
consumer's needs. A number of attributes are presented to the consumer, each attribute capable of being set to 
one of a number of values. Thus, for example, the user sets a color attribute to 'Egg SheH White,' sets an indoor 
water spout attribute to 'No,' and an automatic tee-maker attribute to 'Yes.' The consumer then selects an option 
20 labeled, for example, 'Add Item to Shopping Basket." The Web browser 120 directs a corresponding message to 
the commerce cEent 122 causing information about the selected merchant A refrigerator, including the attributes 
selected, to be stored m a gathered products database 148. (The protocols and software components which enable 
this type of operation to be perforirad are described in the following sections.) Such information includes, for 
example, a picture of the refrigerator, cubic foot capacity, temperature range, energy usage, manufacturer's warranty, 
25 price, the attributes set by the consumer, the URL of merchant site A, and also inchides a preferred payment source 
and a preferred shipping address. The consumer then ends the shopping session wHh merchant site A either by 
accessing a different World Wide Web site or by directng the consumer computer 102 to terminate the network 
connection to the Internet. 

Two days later, the consumer, again having tune to shop, dkects the consumer computer 102 to connect 
30 to merchant site B via the World Wide Web. Merchant »te B also offers refrigerators for sale. After navigating 
through HTML documents describing the features of the refrigerators sold by merchant site B, the consumer selects 
a refrigerator, sets the refrigerator attributes as desired, and invokes the "Add Item to Shopping Basket" option. 
The commands to accomplish this are the same as those required to add the information about the merchant site 
A refrigerator to the shopping basket. The commerce client 122 responds to the invoked option by adding 
35 information about the merchant site B refrigerator to the gathered products database 148. The consumer then 
terminates the shopping session with merchant site B 108. 
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Three weeks later, the consumer uses the consumer computer 102 to con\pare the nformation about the 
merchant site A refrigerator and the merchant site B refrigerator. The consumer does not need to connect to the 
World Wide Web to compare the two refrigerators. The consumer invokes an option entitled, for example, "View 
Items in Shopping Basket." The commerce client 122 extracts the information about the two refrigerators from the 
5 gathered products information 148, and formats the information such that the consumer can view it on the monitor 
1 14. After weighing the features, warranties, and prices of the two refrigerators, the consumer decides to purchase 
the merchant site A refrigerator. 

The consumer then authorizes access to the payment source and address information stored on the 
consumer computer by entering a password known only to the consumer. After the consumer enters the password, 
10 the commerce dent 122 accesses the payment source information 140, decrypts the Biformation, combines it with 
information about the merchant A refrigerator to assemble a goods and services order ('GSO'). The GSO is then 
encrypted and included as part of an HTTP POST message which is sent to the URL of merchant A. Merchant A 
recewBS the massage, decrypts it, processes the order, and ships the product to the consumer's specified shipping 
address. 

15 A few years after purchasing the refrigerator, the consumer examines a product purchaang history to 

determine, for example, whether the refrigerator is still under warranty. The etectronic shopping basket retains a 
complete, browsable history of all products purchased. 
C. CnmnMinicatimi Betwaen Comm erea CHent and CnimnereB Server 

The present bivention extends the functionafity of the standard Web browser 120 by adding shopping-related 

20 features, namely, a shopping basket in which product information can be gathered, a wallet in which sources of 
payment can be stored, and an address book bi which shipping addresses can be recorded. The standard Web 
browser 120, so extended, offers consumers an extremely convenient and consistent method of shopping for products 
over the World Wide Web. This section describes a method for a Web browser to caU functions on both its own 
local computer and also on a computer executing a Web server. Additkinally, a method is described for allowbig a 

25 Web server to call functions on a computer executing a Web browser. 

Figure 2 Ihistrates communication between a consumer computer 102 and a merchant computer 202. A 
consumer accesses a merchant computer 202 on the Internet 204 via a consumer computer 102. The consumer 
computer 102 inchides a standard Web browser 120, and the merchant computer 202 includes a Web server 128. 
The Web browser 120 and the Web server 128 use the HTTP protocol to communicate with each other over the 

30 Internet. 

The Web server 128 running on the merchant computer 202 accesses a local store 144 of HTML documents 
(also commonly referred to as "Web documents" or "Web pages"). When the Web browser 120 on the consumer 
computer 102 requests an HTML document, the Web server 128 retrieves the HTML document and transmits it to 
the Web browser 120 on the consumer computer 102 where it is viewed by the consumer. These documents 
35 typically include information about the merchant, as well as informatkin about the products sold by the merchant 
(including pictures and descriptions of products and product prices). 
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To provide more sophisticated shopping transactions between consumers and merchants, software dedicated 
to providing consumer-oriented shopping functions (the commerce client 122) executes on a consumer's computer, 
and software dedicated to providing merchant-oriented functions (the commerce server 130) executes on a merchant 
computer 202. One objective of the present invention is to provide both a commerce client 122 running on the 
5 consumer computer 102 which communicates directly with the Web browser 120. and a commerce server 130 
running on the merchant computer 202 which communicates directly with the Web server 128. 

The comnmrce cGent 122 and the commerce server 130 utilize the Internet-based communication between 
the Web browser 120 and the Web server 128 to communicate with each other. An extansible Web function calGng 
protocol ("WFCP") permits the commerce client 122 and the commerce server 130 to pass functions calls to each 
10 other by embedding the function caDs in data exchanged via the Intemet by the Web browser 120 and the Web 
server 128. As iDusUated in Figure 2, the Web function-calling protocol effectively "tunnels' function-calling 
information (requests and responses) through an HTTP message stream (shown in dashed Gnes) between the standard 
Web browser 120 and the Web server 128. One significant benefit of the use of HTTP is that it allows the 
consumer computer 102 to communicate with merchant Web sites from behind Internet firewalls 214 which permit 
15 pessage of HTTP traffic. 

The Web server 128 serves HTML documents which mclude embedded function calling information. This 
function calling information is embedded in a hidden form using standard HTML tags, and is provided in a predefined 
format (specified as part of the WFCP) that is recognized by both the commerce client 122 and the commerce server 
130. Generally, the embedded function calling information corresponds to consumer-selectable options (e.g., 
20 hyperlinks or buttons) within HTML documents to aDow a consumer to initiate client-to-server function calls across 
the Intemet by selecting (with mouse or keyboard) transaction optnns. 

Figure 2 illustrates an HTML document 206 being displayed by the Web browser 120. The HTML document 
206 includes a consumer-selectable button 208 associated with a textual description (such as 'buy," "update 
shopping basket." "retrieve price mformation,' or 'retrieve account information") of a corresponding action to be 
25 performed. When the consumer cGcks on this button, correspondmg f unction-calGng information is passed across the 
Intemet as a standard HTTP POST message from the consumer computer 102 to the merchant computer 202. 

The function calBng inf omiation for making a corresponding function call typically mcludes the name of an 
object, an object interface, a method, and an argument list. If the button 208 actuates a "Calculate Tax" option, 
the corresponding function-calling informatnn associated with the button may. for example, inchide the text: 
30 0BJECT-MSTaxEngin8.1 

INTERFACE-ITaxCateulation 
METHOD -CalculateTaxDue 
ARGS-arglist 

This function-calling information is provided in the HTML document along with a target URL (of the merchant Web 
35 site 104, 106) such that an HTTP POST message containmg the information will be sent to the URL if the consumer 
clicks on the button 208. One example of an HTML-coded form of the HTTP POST message is: 



wo 98/21679 PCTAJS97/20624 
•12- 

<HTML> 

<!-WFCP FORMAHED CALL •> 
< FORM ACTION-http://www.merchant.coin/inigJn 
METHOD-"POSr 

5 ENCTYPE-''appGcation/x-www-form-urlencoded* > 

< INPUT type-hidden naine-OBJECT v8lue-MSTaxEngine.1 > 

< INPUT type-hidden name-INTERFACE «alue-iTaxCalculation> 

< INPUT type-hidden name-METHOD valuB-CalculateTaxDue> 

< INPUT type-hidden name- ARCS value-arglist> 
10 < INPUT type-submit vahie- "Calculate Sales Tax' > 

<rFORM> 
</HTML> 

Although the target URL in this example corresponds to the Web ate that is the source of the HTML document, the 
target URL could be that of a different Web site. 

15 Thus, when the consumer clicks on the button 208, the Web browser 120 generates an HHP POST 

message coded using HTML end sends the HTTP POST message to the URL of the merchant Web site 104, 106. 
This message inchides f unction-calBng information (object, interface, method and arguments) to invoke a method (Le., 
a software callable procedure or function) of a method Bbrary 212 on the merchant computer. If multiple functbn 
calls were linked to the button 208, the HTTP POST message would include the function-cailBig information for eech 

20 such function caD. 

Upon receipt of the HTTP POST message, the Web server 128 parses tha message, invokes the commerce 
server 130 (if not already executing) and passes the function-calling information to the commerce server 130. The 
commerce server 130 then invokes the specified object, and passes the arguments to the specified method using the 
specified interface; the commerce server 130 thereby makes the function call on behalf of the commerce client 122. 

25 Depending upon the method called, the function cell may, for example, invohre a query of and/or an update to a 
merchant database. 

This function call will typically produce a response which must be communicated to the consumer computer 
102. (In the context of electronic shopping, the response message may include, for example, price or inventory 
information for a particular product, or the result of a tax cdculation requested by the consumer.) The response 
30 may include a function call or other information directed specifically to the commerce client 122. The Web browser 
120 recehres ail data transmitted from the merchant computer 202 to the consumer computer 101 However, some 
of the data received by the Web browser 120 is further routed to the commerce client 122. 

The Web server 128 transmits data to the consumer computer 102 by first packaging the data as a MIME 
message and then sending the MIME message across the Imemet from the Web server 1 28 to the Web browser 1 20. 
35 If the response message is in the form of an HTML response to be displayed by the Web browser 120, the MIME 
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type of the message will be HTML. If, on the other hand, the response message is directed to the commerce client 
122 (such as when the response includes non-HTML product information), the response message will be tagged with 
a MIME type which corresponds to the commerce client 122. causing the Web browser 120 to forward the message 
to the commerce client 122. 

5 In the preferred embodiment, the MIME type associated with the commerce client is "x-ishopper." The 

message generated on the server side may include information to caD a function on the consumer computer 102, in 
which case the MIME message will include function-calling information. This ssrver-to-ciient function-calling 
information specifies the object, method, interface, and arguments of the client-side function call and is specified 
within the MIME message using the same format (illustrated above) as used for client-to-server function calls. 

10 Upon receiving a MIME message of type "x-ishopper." the Web browser 120 strips off the MIME headers 

end passes the message to the commerce client 122. As described further below, the commerce client 122 acts 
as a MIME handler for messages of type 'x-ishopper.' The commerce client 122 then invokes the method indicated 
in the MIME message on the consumer computer 102 in the same manner performed by the commerce server 130 
on the merchant computer 202. 

1 5 Thus, using HTTP POST messages and MIME messages, function calls are placed on the merchant computer 

202 by the consumer computer 102 and function calls are placed on the consumer computer 102 by the merchant 
computer 202. Advantageously. WFCP is not tied to any specific function or set of functions. Thus, new client-side 
and server-side functions csn be added (and embedded within HTML documents) without modification to the existing 
function-calling components. The WFCP protocol is described in further detal in a copending patent appGcation 

20 entitled SYSTEM AND METHOD FOR MAKING FUNCTION CALLS OVER A DISTRIBUTED NETWORK, filed June 28, 
1996, which is hereby incorporated by reference, in its entirety. 

A further advantage, however, is gained in providing the Web browser 120 with a method to invoke local 
functions on the consumer computer 102. Using the same HTTP POST messege format, the Web browser 120 
invokes local functions by specifying a URL address that resolves to a local port. Rather than addressbig en HTTP 

25 POST message to a remote site on the Web by using a URL similar to 'http:fKvww.sporting_goodsxom', the Web 
browser 120 directs the HTTP POST to the local consumer computer 102 by using the URL '127.0.0.1:100" (note 
that 'tlOO' specifies iocel port 100). This method of directing an HTTP POST message to the bcal computer is 
facilitated by the hical host service of the TCP/IP protocol stack. The URL '127.0.0.1' is a local loop-back address 
recognized by the local host service as identifying the local machine as the recipient of the message. 

30 A port listener process operates on the local machine 102 monitoring a designated port such as, for 

example, port 100. The port listener receives the HTTP POST message, parses the content, and passes function- 
calling data directly to the commerce client 122. Thus, local functions are invoked by selected options coded in and 
hosted by a Web document wherein function-calling information is associated with the selected options. This method 
for making local function calls from a Web browser is described in further detail in a copending patent application 

35 entitled SYSTEM AND METHOD FDR MAKING FUNCTION CALLS FROM A WEB BROWSER TO A LOCAL 
APPLICATION, filed June 28. 1996, which is hereby incorporated by reference in its entirety. 
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It will be appreciated by those skilled in the art that specialized client and server processes provide 
substantial benefits in the context of computer-based shopping. For example, a merchant can conveniently store 
relatively static catalog information as HTML documents. whDe storing relatively dynamic product information (such 
as price and inventory) in a separate database (not shown in Figure 2) which is accessed by the commerce server 
5 130. This product information may advantageously be stored and served in a format which is recognized only by 
the specialized commerce client 122 (as opposed to the standard Web browser 120). Because the commerce client 
122 runs in conjunction with the Web browser 120, the commerce cGent 122 can readily store both consumer- 
selected HTML (catalog) data from Web pages of merchants, and the associated non-HTML product information 
retrieved via client-to-server function calls. 

1 0 As noted above, because aD information is passed via HTTP, the commerce client 1 22 and commerce server 

130 can advantageously communicate through Internet firewaBs 214 which are typically configured to permit the 
passage of TCP/IP messages addressed to port 80 and which, for security reasons, are configured to block 
communications addressed to other ports. 

Although Figure 2 depicts a single Web server 128 interacting with a single conmierce server 130, it will 

15 be recognized that other system configuratnins are possible. For example, multiple Web servers 128 could be 
provided (runnoig on the same machine or on different machines) which interact with a single, shared commerce 
server 130; or, multiple commerce servers 130 could be provided which interact with a single Web server 128. 

Figure 3 illustrates a preferred architecture of e merchant Web site 302 of the computer-based shopping 
20 systm As shown in Fqure 3, the merchant Web site 302 includes a merchant computer 202, a storage device 304 
(corresponding in functkm to the storage device 144 of Figure 2), and an Internet connection 306. Software 
operating on the merchant computer 202 includes a Web server 128, the commerce server 130, and a method 
library 308 (conesponding to the method Ghrary 210 of Figure 2). A collection of Web documents 310 is stored on 
the storage device 304 as are various merchant databases 312. 
25 The merchant Web site 302 may, for example, be a stand alone site which independently serves kiformation 

with respect to a single merchant, or may be in the form of (or a part of) a centralized or distributed electronic mall 
system which serves the infomiation of many different merchants. The Web server 128 is preferably the Microsoft 
Internet Information Server version 1.0, although other conventional Web servers can be used. The commerce server 
130 is preferably in the form of an ISAPI (Internet Server Appfication Program Interface) DLL (dynamic link library) 
30 which runs within the same process space as the Web server 1 28. A CGI saipt, or a DLL which uses another server 
extension API (such as NSAPI from Netscape), could alternatively be used. 
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The Web documents 310 stored on the merchant Web site 302 are preferably coded using HTML. The Web 
documents 310 contain HTML coding which, when received by a Web Browser 120, display various icons or buttons 
on the screen 114 of the consumer computer 102 along with text or pictures comprising the content of the Web 
document. As described above, these icons or buttons comprise selectable options which correspond to shopping- 
5 related transactions. In the preferred embodiment, the Web documents 310 offer consumers options to add product 
information to an electronic shopping basket, view products collected but not yet purchased, view products already 
purchased, enter payment information into an electronic waBet. place shipping addresses in an Biectronic address 
book, as well as order goods from Web-based merchants. These selectable options coded into the Web documents 
310 have function caling information associated with them (as described above) to invoke executable functions on 
10 the consumer computer 102 or back on the Web server 128 when selected. Web documents with embedded cient- 
side function caDs are also preferably stored on the hard disk of the consumer computer 102 es part of the user 
interface of the commerce cfient 130, allowing the user to invoke client-side functions (such as viewing the shopping 
basket) while off-line. 

The method library 308 of the merchant Web site includes methods for performing client services such as 
1 5 retrieval of product information, calculation of sales taxes, and capture of orders. Some of these methods are listed 
and described in Table 1. 



Method 


£)escription 


GetLineltem 


Retrieves product information given SKU (stock keeping unit) 
number or other product identifier. 


GetPnce 


Retrieves price information given SKU number or other product 
identifier. 


CalculateSH 


Calculates shipping and handHng costs given product/s and 
shipping logistics (e.g., shipping address and method). 


CalculateTaxDue 


Calculates shipping and handling costs given product/s and 
shipping logistics 


ProcessOrder 


Captures order submitted by consumer, and processes in a manner 
specified by merchant. 



TABLE 1 

The commerce senrer 130 performs two primary tasks. First, when a request is received for product 
information (via function-calling information embedded with'm an HTTP POST message received by the Web server 
5 128), the commerce server retrieves various data items in connection with a product, such as SKU (stock keeping 
unit) number, product name, product descrvtion, logo, price, expiration date, tax, and shipping charges. This data 
Is packaged as a MIME file of type 'x-ishopper' and sent back to the consumer computer 102 via the Web browser 
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120, as described above. Second, the commerce server 130 captures and processes orders for products submitted 

by consumers. 

In accordance with the present invention, the merchant sites of the system prepare and serve HTML Web 
documents 310 which present uniform Uansaction options, such as View Shopping Baslcet, Show Wallet, and Initiate 
5 Payment. 

Due to the wide varety of inventory management systems and legacy (long-existing and difficuh to change) 
product information databases, as weH as accounts recehrable systems, the commerce server will often comprise 
custom interface software that will change from merchant to merchant. The present invention is primarily concerned 
with the consumer platform. 

10 Softwara ArehiteetiirB of Consumer ComimtBr 

Figure 4 illustrates the software architecture of the consumer computer 102. The architecture comprises 
a conventional Web browser 120 (such as Microsoft's Internet Explorer 2.0, or Netscape Navigator 2.0), the 
commerce client 122, and a commerce client object library 402, and a storage area 112. The commerce client object 
library 402 comprises a shopping basket object 404 having associated shopping basket methods 406, a wallet object 

1 5 408 having associated wallet methods 41 0, and an address book object 41 2 having associated address book methods 
414. The storage area 112 comprises merchant information 41 6, product information 418, payment source data 140, 
and shipping address data 142, all of which has been selectively stored and/or manually entered by the user. 

The Web browser 120 is preferably configured such thet the commerce client 122 is a MIME-handler 
application. Generally, a MIME-handler is a software application designed to provide specialized processing of specific 

20 types of fles received over the Internet by a Web browser 120. The Web browser 120 of the present invention 
is configured to essociate the MIME type "x-ishopper" with a certain file name extension such as 'ish." When the 
Web browser 120 receives a fib of type "xishopper," the Web browser will cause the commerce cBent 122 
application to begin executing (if not already runnnig). The Web browser 120 will then pass the recehred "x-ishopper" 
fie to the conmierce client 122 for further processing. Extending the functnnality of a Web browser by configuring 

25 the Web browser to associate specific file types with file name extensions end then associating specialized MIME- 
handler appfications with file name extensions is well known and win not be further discussed herein. 

The commerce client 122 executes on the consumer computer 102 as a separate process from the Web 
browser 120 and is a standard executable program. The commerce client 122 begins executing when launched by 
the Web browser 120 upon the Web browser's receipt of a file of MIME type 'x-ishopper." Another way in which 

30 the commerce client 122 begins executing is when a local port listener task receives a message from the Web 
browser 120 which was directed at a local port. The port Ostener launches the commerce client 122 if it is not 
already executing. 

Still another way of launching the commerce client 122 is by running the commerce client program directly. 
As explained below in more detail, many functions ('locai' functions) of the commerce client 122 do not require an 
35 Internet connection or transmission of data to or from a Web site. These local functions are available via user- 



wo 98/21679 PCT/US97/20624 
-17- 

interface HTML documents which reside on the consumer computer's hard disk. The commerce client 122 executes 
until the consumer selects an option causing the commerca client 122 to stop executing. 

When the commerce client 122 starts running, it performs an initial task of loading structures in memory 
from data stored on the hard disk or other fixed storage media. The data represent merchant information, product 
information, payment source mformation, and shipping addresses. The data are stored in such a way as to be easily 
read into memory while maintaining relationships (links) among the data. Such construction of interlinked in-memory 
structures from data stored on a hard disk is weO known in the art. When the commerce client 122 shuts down 
or otherwise terminates normally, it writes the interlinked in memory structures to hard disk storage in a manner that 
inreserves all the rslationshq)s among the data. 

The data comprising the in nHmiory data structures are accessed and manipulated through objects. The 
shopping basket object 404 is associated with shoppmg basket methods 406 which read, write, modify, and display 
information about merchants and/or products of interest to the consumer. The shopping basket methods 406 interect 
primarily with in-memory structures comprising product and merchant information. In accordance with the present 
invention, data for each product are preferably organized Into groups as shown in Table Z 



Product Data Field 


Description 


Logo 


Picture associated with product. 
Type: VOID* 


LogoSize 


Size of Picture associated with product. 
Type: DWORD 


Name 


Name of product. 
Type: Cstring 


Oescrqition 


Description of producL 
Type: Cstring 


Nee 


Unit Price of product. 
Type: Currency 


Quantity 


Quantity of product to order. 
Type: Float 


ExpirationDate 


Date on which offered price expires. 
Type: Cstring 


Tax 


Amount of tax computed for sale of product. 
Type: Currency 


ShippingCharge 


Cost to ship product as ordered. 
Type: Currency 
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Product Data Field 


Description 


OtherCharges 


Miscellaneous additional charges associated. with order. 
Type: Currency 


SKU 


Stock Keeping Unit, merchant's identifier for product 
Type: Cstring 


ShipMethod 


Delivery services to be used in shipping product. 
Type: Cstring 


drderUHL 


URL string identifying Web site to send order for product 
Type: Cstrmg 


ReferenceURL 


URL string identifying Web site for information about the product 
Type: Cstring 


PaymentFriendlyName 


Reference to entry in Payment Database identifying source of payment if 
product is ordered (e.g., Visa, Checking Acct., etc.) 
Type: CString 


AddressFriendiyNaine 


Entry in Shipping Address DB identifying where to ship product 
Type: CString 


1 Flags 


0 if product has not been purchased; 1 if product has been purchased 
Type: DWORD 



TABLE 2 

There may be a variety of properties associated with a product which are umque to that product and are 



not associated with other products. Such properties are represented in name/value pairs in memory and can be 
referenced from an in memory product structure through an associated pointer to a linked list of such properties. 
5 The property data are organized as shown in Table 3. 



1 Property Data Field 


Oescrqitbn 


1 Name 


Name of property 
Type: Cstring 


Value 


Value of property 
Type: Variant 


Flags 


Stores various flag values 
Type: DWORD 



TablH 

Merchant data preferably comprise associated fieUs as shown in Table 4. 
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Logo 


Logo associated with merchant. 
Type: VOID* 


Logosize 


Size of logo associated with merchant. 
Type: DWORD 


Name 


Name of merchant. 
Type: Cstring 


LineltemList 


Pointer to Bnked list of product data structures 
Type: Pointer 



The waDet object 408 is associated with wallet methods 410 which provide access to payment source data 
(such as credit card numbers and checking account numbers) used for making on-line purchases. Payment source 
data are stored in memory preferably according to associated fioMs as shown in Table 5. 



Payment Data Field 


Description 


FriendlyName 


Easily remembered and recognized name for payment source 
Type: Cstring 


CardNumber 


Credit card or account number 
Type: Cstring 


ExpirationDate 


Date on which credit card expires. 
Type: Cstring 


CustomerName 


Name of card holder or account holder 
Type: Cstring 


issuingBank 


Name of bank issuing credit card or account 
Type: Cstring 


BiUToAddress- 
FriendlyName 


Reference to address database bidicating address to be billed when 
payment source is used to order product. 
Type: Cstring 



The address book object 412 is associated with address book methods 414 which access address 
information for shipping purposes. The address book methods 414 access address data preferably organized as 



shown in Table 6. 


Address Data Field 


Description 1 


FriendlyName 


Easily remembered end recognized name for addresses 1 




Type: Cstring 
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Name 


Name of person to receive parcels at address 
Type: Cstring 


Addressi 


First text line of shipping address. 
Type: Cstring 


Address^ 


Second text Hne of shipping address 
Type: Cstring 


AddressS 


Third text line of shipping address 
Type: Cstring 


City 


Name of city of shipping address 
Type: Cstring 


State 


Name of state of shipping address 
Type: Cstring 




Zip code of shipping address 
Type: Cstring 


Country 


Name of country of shipphg address 
Type: Cstruig 


Phonel 


First phone numher associated with shipping address 
Type: Cstring 


Phone2 


Second phone number associated with shipping address 
Type: Cstring 



The shopping baslcet object 404, wallet object 408, and address book object 412 are preferably 
implemented as in-process COM (component object model) compfiant objects, implemented as a single DLL (dynamic 
link Gbrary). The component object model is welknderstood m the art and will not ba further discussed. One skilled 
5 in the art will, however, appreciate that callable functions with appropriate associated data structures could be used 
in place of the shopping basket object 404, the walbt object 408, and the address book object 412 and their 
respecthre associated methods 406, 410, 414. 

Hgure 5 iUustrates generally tbe type of data accessed by the primery objects of the commerce cGent. A 
shopping basket object 502 accesses and manipulates merchant data structures 504, product data structures 506, 
10 and product property data structures 508. A wallet object 510 accesses and manipulates payment source data 
structures 51Z An address book object 514 accesses and manipulates address book data structures 518. 

As described above, the commerce cSent 120 responds to various function-calling information embedded in 
MIME files of type "x-ishopper" passed from the Web Server 128 through the Web browser 120, and also responds 
to function-calKng information received indirectly from the Web browser 120 by way of a bical port to which the 
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Web browser directs data meant for the commerce client 122. The function-calling information identifies objects and 
methods which the commerce client 122 invokes. 

When viewing a Web document 310 which, for example, describes a product (hosts an item) and which is 
coded according to the present invention, the standard Web browser displays an ADD ITEM-type option to the 
5 consumer which allows information about a product to be stored in the electronic shopping basket (in computer 
memory, and eventually written to a hard disk). The ADD ITEIM option can be selected, for example, when the 
consumer has interest in the product, even if the consumer has not yet decided to purchase the product. The Web 
document 310 will also typically include a product form which is displayed on the consumer's computer screen. The 
product form represents a number of attributes whmh can be set by the consumer by filling in values. After setting 

10 attributes as desired (e.g., selecting a size or color for the product), the consumer selects the ADD ITEM option to 
store such "user preference* attr3)utes along with the information provided by the merchant. 

Figure 6 illustrates the steps performed when a consumer selects the ADD ITEM option. In a first step 
602 the Web browser 120 issues an HTTP POST message to the Web server 128 indicating that a consumer has 
selected an ADD ITEM optton. In a next step 604, the Web server 128 retrieves product information from the 

15 merchant web site and sends the information to the Web browser 120 as a MIME message of type "x ishopper." 
Next, in a step 606, the Web browser 120, after establishing receipt of a MIME message of type x-ishopper, 
launches the commerce cfient 122 (if it is not abeady running). The commerce client, m a step 608, constructs an 
in-memory representation of merchant, product, payment, and address data read from a hard disk. Then, in a step 
610, the Web browser 120 passes the MIME message to the commerce client 122. 

20 The commerce client 122 uses function-calling information embedded in the passed MIME message to call 

a method AddLineltem. In the step 812, the AddLineltem method navigates memory structures (constructed in step 
608) looking for a merchant data structure with a name field matching the merchant name passed with the MIME 
message. If no such merchant structure is found m the step 812, then a new merchant structure is appended to 
the linked list of merchants by allocatmg memory and the new merchant structure is populated with merchant data 

25 from the passed MIME message. The AddLineltem method then, m a next step 614, navigates a linked list of 
product data structures associated with the merchant structure (either found or Greeted in the step 612). Each 
product data structure in the list represents one product offered for sale by a merchant. In the step 616, the 
AddLineltem method allocates memory for a new product data structure and populates it with data packaged in the 
MIME message such as product SKU, price, quantity, description, name, logo, color, or size. The AddLineltem method 

30 then links the new product data structure to the end of the linked product data structures for the merchant. 

In a step 618, the commerce client 122 invokes a SetltemProperty method wherein the linked list of 
merchant structures is again navigated until a merchant structure having a merchant name matching the passed 
merchant name is found. In a step 620, the product data structures referenced by the merchant structure are 
navigated until a product data structure is found having an SKU f»ld equivalent to the SKU number passed in the 

35 MIME message. Then, in the step 622, the SetltemProperty method nav^ates a finked list of properties referenced 
by the product data structure found, and does so for each property passed in the MIME message. When a property 
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Structure is found whose name matches the passed property name, the value associated with the matched property 
name is replaced with a value passed in connection with the property name. In each case where the property list 
is navigated and no matching property name is found, the SetltemProperty method appends a new property data 
structure to the linked list of properties. The SetltemProperty method allocates memory for the new property data 
5 structure and fiBs in the name and value and flag fields as appropriate from the data bi the passed MIME message. 

In a step 624, the commerce client 122 then executes the steps comprising the VIEW SHOPPING BASKET 
option described below. Thus, when the steps comprising the ADO ITEM option are completed, a new product data 
structure is stored in memory comprising data fields such as SKU, price, quantity, picture, description, reference URL, 
and merchant information. Also, any special properties associated with the product such as size, color, or finish, 

10 are also stored with the new product data structure. As explained below, default payment source infomiation and 
default shipping address information are also associated with a new product data structure. 

Web documents 310 served by Merchent Web sites and/or stored locally on the consumer computer 102 
offer consumers a selectable option called VIEW SHOPPING BASKET. This option allows consumers to retrieve a 
list of aD the products that have been placed inside the electronic shopping basket using the ADD ITEM option. 

15 Figure 7 illustrates the steps in carrying out the VIEW SHOPPING BASKET option. In a first step 702, the 

consumer selects the VIEW SHOPPING BASKET option from within the Web browser. In a next step 704, the Web 
browser 120 issues a local function call. Than, h a step 706, the commerce cfient 122 is launched (if not already 
executing) by a local port monitor detecting the bcal function call. Next, in e step 708, the commerce client 122 
loads the shopping basket COM object. In a next step 710, e veriable CheckFlag is set equal to 0. Then, in e step 

20 712, a loop Is entered and is executed once for each merchant data structure. 

In a step 714, the commerce client 122 invokes a GetFirstltem method. In the step 714, the GetFirstltem 
method navigates to a given merchant, in this first iteratun of the bop, the given merchant wBI simply be the fn-st 
merchant in tha merchant data structure list. In the step 716, the linked Est of product data structures referenced 
from the first merchant data structure is navigated to the first product data structure. If, in the step 718, it is 

25 determined that there are no product deta structures for this merchant or the navigation of the product data 
structure list has reached the end of the list, then, in a step 720, the GetFirstltem method returns a value of 0. 
If in the step 718 it is determined that another product data structure exists and that the end of the product data 
structure list has not yet been reached, then the flag field of the product data structure is compared against the 
CheckFlag variable. Because CheckFlag is equal to 0, the product flag is being compared against the value 0 which 

30 would indicate that the product has not yet been purchased. If in the step 722, it is determined that the product 
flag is not equal to the CheckFlag then processing reverts back to the step 718 to check the next product data 
structure in the list. If, however, in the step 722, the product flag is equal to the CheckFlag, indicating that the 
product has not yet been purchased, then in a step 724, a pointer is returned pointing to the product data structure 
of the product that has not been purchased and the name of the product that has not been purchased is added to 

35 a list box structure. Next, in a step 726 the pointer to the product data structure is saved and iterations of the 
loop are termniated. 
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In the step 728, the GetNextltem method is invoked which begins by navigating to a given merchant. In 
the step 730, a current chain of linked product data structures is navigated to a point equal to a saved pointer 
location (the pointer location saved in step 726 if this invocation of GetNextltem immediately follows the termination 
of the GetFirstltem method, otherwise the pointer location saved in the step 742 is used). Next, in the step 732, 
5 the next product data structure in the linked list is examined. If in the step 734 it is determined that the end of 
the product data structure list has been reached then in the step 736, a 0 is returned. If, however, in the step 734 
it is determined that the end of the product data structure list has not yet been reached then, in the step 738, the 
product flag is compared against the CheckFlag. If in the step 738 the product flag is not equal to the CheckFlag 
then processing resumes in the step 732 examining the next product data structure in the list. If, however, in the 

10 step 738 the product flat is equal to the CheckFlag then, in the step 740, a pointer is returned to the product data 
structure and the name of the product is added to the Est box structure. Next, in the step 742, a pointer to the 
product data structure is saved. The GetNextltem method is then invoked again beginning at step 728 where the 
Est of merchant data structures is navigated to the current merchant and the steps 728 through 742 are repeated 
until the end of the merchant data structure is reached. 

15 When, in a step 744, the end of the merchant data structure Est is reached, then in a step 746 a scrollable 

list of product names appears on the consumer's computer screen. The fist of prodact names corresponds to all 
products currently in the electronic shopping basket which have not yet been purchased. 

Web documents 310 also offer consumers a VIEW HISTORY option. By selecting VIEW HISTORY, a list 
of product names is displayed on the user computer, all of which have been purchased. In one embodiment, the 

20 steps iOustrated in Figure 7 in relation to the VIEW SHOPPING BASKET option are aD perfomied m relation to the 
VIEW HISTORY option with one exception. In performing the VIEW HISTORY option, the CheckRag variable in the 
step 710 is set equal to 1 instead of 0. Thus modified, the steps detect all product data structures whose flags 
are set to 1 indicating that thay have already been purchased. The steps of Figure 7 then construct a list of product 
names reflecting all of the products that have been purchased. 

25 In another embodiment, selecting the VIEW HISTORY option causes a Est of all product orders to be 

displayed. Eech merchant structure has a reference pointer to a list of order structures. Each order structure, in 
addition to havmg fields for payment shipping, and order tracking information, also has a reference pointer to a list 
of product structures. Thus, the Enked Est of merchants is traversed. For each merchant, the respective merchant's 
Est of order structures is traversed. One display item is generated from each order structure. Each display item 

30 shows on the screen of the user computer, the purchase date, the payment information, the shipping address, the 
order tracking identifier, and the products ordered. Note, the products ordered are determined by traversing the 
Enked fist of product structures associated with each order structure. The VIEW HISTORY option advantageously 
allows consumers to examine past purchases whether such purchases occurred very recently or many years ago. 
The VIEW SHOPPING BASKET and VIEW HISTORY options do not require a connection to the Internet to 

35 operate. In addition, these functions cen optnnally be invoked without using the Web browser. To perform these 
functions without a Web browser 120, the consumer mitiates execution of the commerce client 122 by, for example. 
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using a mouse and double-clicking an icon present on a graphical user interface of the consumer computer 102 (an 
icon with which the commerce client 122 executable program is associated). A commerce client user interface offers 
consumers a selection of options which do not require a connection to the Internet. These options are noted below 
to distinguish them from options which require Web-based communication. 
5 Web documents 310 of the system may also host a DELETE ITEM option to remove an item from the 

electronic shopping basket. Figure 8 illustrates the steps performed to carry out the DELETE ITEM option. In a first 
step 802, the consumer selects the VIEW SHOPPING BASKET option and is presented with a list of products which 
have been gathered but which have not been purchased. The DELETE ITEM option is then presented. 

In a next step, 804, the consumer selects a product name from the list. Then, in a step 806, the consumer 

10 either selects the DELETE ITEM button or presses the delete key of the keyboard. The consumer is then prompted 
to confirm the deletion in a step 808. If the consumer does not confirm the deletion in the step 808, then, in e 
step 810, the steps of Figure 8 temmnate. If, however, m the step 808, the consumer does confirm the deletion, 
then the DeleteLineltem method is invoked. 

A next step 812 than uses a pointer to the product data structure of the selected product to locate the 

15 preceding product data structure in a linked list. Locating a preceding structure in linked list is preferably done by 
implementing the list as a double linked list (one whose structures point both to the next structure as well as the 
preceding structure). It is possible that there is no precedbig product data structure, that is, that the product data 
structure for the selected product is the first in the ist of such product data structures that is referenced by a 
merchant data structure. In any case, a pointer to the product data structure will be located, it will simply belong 

20 to a merchant data structure rather than to a precedmg product data structure. 

In a step 814, the same pomter to the product data structure of the selected product is used to locate a 
followbig product data structure (Le., one which follows the product data structure corresponding to the selected 
product). It is possible that there is no followmg product data structure or, in other words, the product data 
structure of the selected product has a NULL pomter to the next product data structure. 

25 Finally, in a step 816, the pointer located in the step 812 Flb.. the pomter which points to the product data 

structure of the selected product) is set to point to the product data structure which follows the product data 
structure of the selected product In the case where there is no product data structure f oDowing the product data 
structure of the selected product, then the pointer heated in the step 812 is simply set to NULL. Thus, the product 
data structure of the selected product is no kinger referenced (is deGnked) from the in-memory data structures and 

30 is effectively deleted. The DELETE ITEM optnn is offered to consumers via the commerce client user interface as 
wen as on Web documents displayed by the Web browser 120. 

Another option that is presented to a consumer following selection of the VIEW SHOPPING BASKET option, 
is an option to SEE ITEM DETAILS. The SEE ITEM DETAILS option allows a consumer to check the value of the 
unique properties of a product (e.g., a selected color or size) as well as the payment source to be used in connection 

35 with a purchase and also the address the product is to be shipped to if ordered. 
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Figure 9 illustrates the steps performed in relation to the SEE ITEM DETAILS option. First, in a step 902, 
the consumer selects the VIEW SHOPPING BASKET buHon and is presented with a list of products. In a next step, 
904, the consumer, selects a product name from the list Then, in a step 906, the consumer selects the SEE ITEM 
DETAILS button. 

5 The Web browser 120 then, in a step 908, sends a local HTTP POST message directed to a local port. 

A port listener responds to the message in a step 910, and forwards the message to the commerce client 122 in 
a step 912. 

In a step 914, the commerce client 122 uses a pointer to the product data structure of the selected 
product (this pointer is maintained following the selection of the product in connection with the VIEW SHOPPING 

10 BASKET option) to conveniently locate the product data structure of the product selected. Next, in a step 916, a 
drop-down box is created having the Friendly Name of a payment source (i.e., the value associated with the 
PaymentFriendlyName field of the product data structure) as the only entry. Similarly, in a step 918, a second drop- 
down box is created having the Friendly Name of a shipping address (i.e., the value assodated with the 
AddressFriendlyName field of the product data structure) as the only entry. 

1 5 A method GetFirstProperty 922 is then invoked and, in a step 920, the GetFirstProperty method, examining 

the contents of a property list pointer associated with the product data structure of the selected product, tocatas 
the first property data structure in e linked list of property data structures referenced by the product data structure. 

Next, a method GetNextProperty 924 is repeatedly called in a step 926 to navigate the linked list of 
20 property data structures. In a step 928, a Est box is created havmg an entry for each property name / property 
vahiB pair encountered in navigating the linked list of property data structures. 

In a step 930, a GetPaymentFvstFriendlyName method 932 is invoked to examine the root pointer to the 
linked payment source structures end to return the value of the Friendly Name of the first payment source structure. 
A Friendly Name, as discussed bebiw, is simply a name Eke "Bob's Visa Card' which is conveniently used to 
25 designate a payment source. In the step 934, the GetPaymentNextFriendlyName method 936 is used to navigate 
the linked Tist of payment source structures, piecoig the Friendly Name of each in the drop-down box already created 
in the step 918. 

In a next step 938, a GetAddressFirstFriendlyName method 940 is invoked to exambie the root pointer to 
the linked shipping address structures and to return the vehie of the Frienily Name of the first shipping address 
30 structure. A Friendly Name, as used with respect to an address, is a name like 'the office" or "Debbie's house" 
which is conveniently used to designate a shipping address. In the step 942. the GetAddressNextFrtendlyName 
method 944 is used to navigate the linked list of shipping address structures, placing the Friendly Name of each in 
the drop-down box already created in the step 918. 

Thus, a consumer can browse a list (displayed on the consumer's computer 102 screen as a scrollable list 
35 box) of all propertns and their correspondng vahies associated with the selected product and can modify the 
property vahies if desired. Also, the consumer can select from either of the two drop^lown boxes displayed on the 



W09»21679 PCT/US97/20624 
-26- 

consumer computer 102 to change the payment source to be used to purchase the product or to change the shipping 
address for delivery of the product if purchased. 

In a step 946, a choice box is displayed to the consumer offering the choices OK or CANCEL. If, in the 
step 948, it is determined that the consumer selected CANCEL, then, in a step 950, the list box and the two drop- 
5 down boxes are cleared from the consumer computer and the steps of Figure 9 terminate. If, however, in the step 
948, the consumer selected OK, then, in a step 952, a SetltemProperty method 954 is invoiced to replace the values 
of the properties modified by the consumer, as well as to replace the Friendly Name for payment source or shipping 
address if either was changed by the consumer. The SS ITEM DETAILS option is present on the commerce client 
user interface as well as on Web documents. 

ID To manage payment source mformation, the present mvention also aDows a consumer to view and modify 

the contents of an electronic wallet A Web document hosts (provides to a consumer) the option VIEW WALLET and 
mchides embedded function-calling information which invokes wallet-related functions. It will be understood that the 
Web browser 120 generates a HTTP POST message directed to the local consumer computer 102, and that a port 
listener process receives the message and passes it to the commerce client 122 and also launches (executes) the 

15 commerce cBent if necessary. 

Figure 10 illustrates the steps perfornied in connection with viewing and manipulating payment source data. 
In a first step 1002, the consumer selects the VIEW WALLET option. Next, in a step 1004, the commerce client 
122, having received the function-calling information from the port listener, loads the wallet object. In a step 1006, 
the GetPeymentRrstFriandlyName method 1008 is invoked to examine a maintained root pointer (a pointer to the first 

20 in a linked Ost of payment source data structures) to determine the value of the Friendly Name associated with the 
first payment source data structure. This first Friendly Name is used as the first entry in a list box. Next, in a step 
1010, the GetPaymentNextFriendlyName method 1012 is invoked to traverse the linked Bsl of payment source data 
structures and place the Friendly Name associated with each as an entry m the list box. 

In the step 1014, a browsabla fist box is displayed to the consumer, listing all Friendly Names assigned to 

25 payment sources. In a next step 1016, options to ADD, EDIT, DELETE payment sources are presented to the 
consumer, as is an option to MAKE PREFERRED (establish as the default) one of the payment sources. 

If, in the step 1016, the consumer setects the ADD payment source option, then, in a step 1018, a dialog 
box is displayed with blank or incomplete fields corresponding to payment source information. The fields are designed 
to elicit mfoimation such as credit card number, issuing bank, expiration date, name on card, Friendly Name, and 

30 biffing address. The consumer can enter inforniatian corresponding to a credit card, debit card, or any other cash 
substitute. Then, in a step 1020, the consumer fills in the fields and, if the consumer desires to retain the entered 
information in the electronic wallet, the user is prompted to enter a password twice for verification in a step 1022. 
When the passwords are typed correctly twice, then in a step 1024, the password is used to encrypt the entered 
payment source data, and the encrypted data is stored in association with the Friendly Name entered by the 

35 consumer which is not encrypted. The consumer can then exit from viewing the wallet or continue with further 
manipulations of payment source data. 
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If, in the step 1016, the consumer selects EDIT payment source data, then upon selecting a Friendly Name 
corresponding to payment source data, the consumer, in a step 1026 is prompted to enter a password. If the 
password is correct, it is used to decrypt the encrypted payment source information associated with the selected 
Friendly Name, in a step 1028, the decrypted payment source information is presented to the consumer in a dialog 
5 box. The data are broken into fields for consumer editing. 

in the step 1030, the consumer modifies the data fields. When the consumer is finished updating payment 
source information, the consumer, in a step 1032, is prompted to enter a password twice. This password may be 
different from the password entered earlier to access the payment source dete. When the password is successfully 
entered, the updated payment source data is encrypted and stored in association with the Friendly Name (which is 

10 not encrypted). Password protection at the consumer computer 102 level is en adventage of the present invention 
which ensures that only one person has access to credit card numbers end other financial information. 

In the step 1016, the consumer may elect to DELETE payment source data. Upon selecting from the list 
box of step 1014 a Friendly Name corresponding to payment source data to be deleted and also selecting the 
DELETE payment source option, the consumer is asked, in a step 1036, to confirm the deletion request. If the 

15 consumer confirms the deletion, then payment source data associated with the selected Friendly Name is removed 
from the finked ist of payment source data structures, it will be appreciated by those skilled in the art that a 
password prompt can be edded to the deletion steps to protect against undesired deletions. 

The step 1018 also offers the option to MAKE PREFERRED one of the payment sources. Making a 
payment source preferred ceuses its Friendly Name to be associated by default with product information that is 

20 added to the electronic shopping basket. Generelly, e preferred payment source would be an often used credit card 
account perhaps offering a very competitwe interest rate or earning for the cardholder airline frequent flyer miles 
whenever money is spent. If the consumer, in the step 1016, selects a Friendly Name from the list box of step 
1014, and then selects MAKE PREFERRED, the Friendly Name selected becomes, in the step 1040, essociated with 
the default payment source. One of ordinary skill will understand that a confirmation check couM be added to the 

25 MAKE PREFERRED steps to svoid un'mtanded replacements of e prnr default payment source. When the consumer 
is finished vnwmg and manipulating payment source dete, the user terminates the VIEW WALLET options and screen 
display by selecting an EXIT (or similarly labeled) button. 

Very similar to the manner in whnh the present inventnn facilitates viewing end manipulating payment 
source data in the electronic waDet is the manner in which it permits consumers to view and manipulate shipping 

30 address data in the electronic address book. Figure 1 1 illustrates the steps in viewing or manipulating address book 
data. In a first step 1102, the consumer selects a VIEW ADDRESS BOOK option. In a next step 1104, the 
commerce client 122 loads the address book object. 

In a step 1106, the Get AddressFirstFriendlyName method 1108 uses a maintained root pointer (always 
points to the first of a linked list of shipping address data structures) to examine the first shipping address data 

35 structure and to return the associated Frnndly Name. A Friendly Name for a dipping address might be, for example. 
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"My Castle,' or "Jill's Office." The Friendly Name associated with the first shipping address data structure Is used 

as the first entry in a browsable list box. 

Next, in a step 1110, the GetAddressNextFriendiyName method 1112, Is used to traverse the linked list 

of shipping address data structures and to include the Friendly Name associated with each structure in the list box 
5 created in step 1106. The list box is displayed to the consumer in step 1114. A step 1116 presents options to 

the consumer to ADD, EDIT, DELETE shipping address data, as well as to MAKE PREFERRED a shipping address. 
If, in the step 1 1 1 6, the consumer elects to ADD shipping address data, then, in a step 1 1 1 8, a dialog box 

is displayed to the consumer containing blank or incomplete fffilds corresponding to shipping address data such as 

street address, city, state, country, zip code, name, and Friendly Name. In a next step 1120, the consumer enters 
10 information into the fields. When the consumer is satisfied that the information is complete and accurate, the 

consumer selects the OK button in the step 1122, end the new shipping address is seved in association with the 

new Friendly Name entered. 

As with the electronic wallet, the consumer can also elect to EDIT data in the ebctronic address book. 

Because there is not as much need for security, there is no password access to or encrypting performed on the 
15 shipping address data. One skiBed in the art will understand that password-protected access could be implemented 

in connection with the shipping address data as specified with respect to the payment source data. If the consumer 

elects to EDIT shipping eddress data, then, after selecting a Friendly Name from the browsable list displayed in the 

step 1114, a diatog box is displayed in a step 1124 presentmg fielded data items corresponding to the existing data 

associated with the selected Friendly Name. In the step 1126, the consumer modifies the existing shipping address 
20 data. When satisfied that the changes are complete, the consumer selects an OK button in a step 1 1 28 which saves 

the changed shipping address information in association with the Friendly Name (which may have just been changed 

by the user). 

If, in the step 1116, the consumer elects to DELETE shipping address data, then, efter selecting a Friendly 
Neme correspondmg to e shipping address, the user is prompted in a step 1130 to confirm the delete request. If 
25 the consumer confirms the delete request in the step 1 130, then in e step 1 132 the shipping address data is deleted 
along with the Friendly Name. 

If the option to MAKE PREFERRED a shipping address is selected in the step 1116, then, in a step 1134 
the shipping address data associated with the selected Friendly Name is associated with the default shipping address. 
Thereafter, any products placed mto the electronic shopping basket will acquire automatically, by default, an 
30 association with the new shipping address. One skilled in the art wiH appreciate that a confirmation step such as 
that in step 1130 with respect to deleting shipping address data could be added to safeguard against unintended 
modifications to the default shipping address. Note that both the VIEW WALLET and VIEW ADDRESS BOOK options 
are available from the commerce client user interface. 

With payment source information in the electronic waDet and shipping address information in the electronic 
35 address book, the present invention enables e consumer to purchase products m the electronic shopping basket. Web 
documents host a READY TO BUY option. 
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Figure 12 illustrates tlie steps of purchasing a product. In a first step 1202, the consumer selects the 
READY TO BUY option. Next, in a step 1204, the shopping basket object is loaded. Then, in a step 1206, the 
GetFirstltem method 1208 is used to examine a maintained root pointer to the first merchant data structure and to 
then traverse and examine the linked list of product data structures associated with the first merchant and return 
5 the first located unpurchased product. The Flag of each product data structure is examined to determine if the 
product is already purchased. If no unpurchased products are discovered in association with the first merchant data 
structure, the GetFirstltem moves to the next merchant structure in the linked list of merchants. The GetFirstltem 
method returns information (such as a pointer) identifying the first product structure associated with an unpurchased 
product encountered in its traversal of the merchant and product structures. 

10 In a next step 1210. the GetNsxtltem method 1212 is used to compiate the traversal of the merchant and 

product structures, returning information identifying all product structures associated with unpurchased products. 
In a step 1214, a list of all unpurchased products is generated and is then sorted by merchant and by 
PaymentFriendlyName. Next, in a step 1216, the list of unpurchased products is displayed to the consumer, and 
the consumer is prompted to confirm the purchase request. If, in the step 1216. the consumer confirms the 

15 purchase, then the wallet object is loaded in a step 1218. Otherwise, the steps of Figure 12 are terminated and 
no purchase occurs. 

With the unpurchased product items in the electronic shopping basket sorted by merchant (B.g. 'L.L. Bean' 
or 'Seers'), a step 1220 dwides the product items into groups, one group per merchant. A first product group 
associated with a first merchant is designated for processing. A step 1222 then divides [or sorts) the first group 

20 into further subgroups according to the value of the PaymentFriendlyName (e.g., "Gold Card' or 'Mary's Amex'). 
Thus, different orders can be submitted to one merchant, but paid for using different payment sources. 

One having ordinary skill in the art will appreciate thet a third subgrouping could be performed such as. 
for example, a subgrouping based on the value of AddressFriendlyName(e.g.. 'Grendma's House' or 'Alaska Cabin'). 
Such an additional subgrouping would conveniently support orders which could be submitted to one merchant, cause 

25 payment from different payment sources and assist the merchant in shippbig products to different locations. Further, 
products paid for from the same payment source could conveniently be shipped to different addresses. 

Associating a group of producu for a single merchant that are to be purchased from a single payment 
source, a 6S0 (goods and services order) is submitted to the GenerateGSOPI method 1242 on the wallet object. 
In a step 1224, the GenerateGSOPI method 1242 extracts the stored and encrypted data (or blob) associated with 

30 the passed PaymentFriendlyName. In a next step, 1226, the consumer is prompted for a password to authorize 
payment from the payment source associated with the passed PaymentFriendlyName. If the password is incorrect, 
the purchase is not authorized and the next subgroup of products is identified whereupon step 1222 repeats. If, 
however, the password is correct, then the encrypted payment source data is decrypted in a step 1228, and a 
payment instruction is formed from the payment source information and the product information. The payment 

35 instruction contains data sufficient to albw a merchant to complete the order. In a next step, 1230. the payment 
instruction along with the product Bst is passed to an encryption DLL to be encrypted. The encryption DLL uses RSA 
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encryption technology (a form of public/private key encryption) which is known. The present invention is not limited 
by encryption technology, and other forms of encryption could be used. The GenerateGSOPI method 1242 then 
passes the encrypted order to a step 1232 wherein the order is sent to a merchant's order URL (held as a field 
associated with a product data structure) as part of an HTTP POST message. Thus, the commerce client 122 is 
5 able to bypass the Web browser and transmit HTTP POST messages itself. 

After transmitting an order, the commerce client 122 then updates the in memory structure for the 
respective merchant. Each merchant structure includes a reference pointer to a linked list of order structures. The 
commerce client 122 traverses the linked list of order structures, if any, to reach the final order structure. The 
commerce cfient 122 allocates memory for a new order structure, links the new structure to the list of order 

1 0 structures for the merchant, and then populates the new order structure with payment information, shipping address 
informatnn, and a pointer to the product structure associated with the product ordered. An order tracking identifier 
COT!') field of the new order structure is left blank. One skiDed in the art will appreciate that linked lists of 
structures is merely one way of associating data items together, and that other methods such as relational databases 
can be used to accomplish a similar association. 

15 A merchant site recehring a product purchase order transmits an order confirmation message to a Web 

browser 120. The order confirmation message transmits an order tracking identifier COTn to the Web browser 120. 
The Web browser 120 displays the Oil on the screen of the user computer, along with a message which states, 
for example. Thank you for your order. If there is any problem, please phone 1 800 123 4567 and be prepared 
to refer to the following order tracking identifier.' The OTI is also embedded in a MIME message of type x-ishopper 

20 which is passed by the Web browser 120 to the commerce cEent 122. The commerce cGent 122 then copies the 
OTI to the blank OTI field of the order structure, thus completing the storage of information related to the purchase. 

A step 1234 determines whether additional products for the current merchant remain to be purchased. If 
so, processing resumes at the step 1222, and, if not, processing resumes upon the next group of products from the 
next merchant at the step 1220. A step 1236 determines whether afl products for all merchants have been 

25 purchased. If not, then processng resumes with the step 1220. if aD products have been purchased as determined 
by the step 1236, then the Flag field for every product m the electronic shopping basket is marked 'purchased' (Le., 
set equal to 1). Finally, in a step 1240, the steps comprising the VIEW SHOPPING BASKET option and the VIEW 
HISTORY option are mvoked to force updates to memory structures and screen displays to avoid confusion as to 
whether any product was in fact purchased. 

30 An ORDER STATUS option is presented to a user by the commerce client 122 after selection of the VIEW 

HISTORY option. Once a list of orders is generated and displayed to the user as described above, the user selects 
an order (preferably by positioning a mouse pointer over information associated with an order and clicking a mouse 
button). The user then selects the ORDER STATUS option. The commerce client then generates an HTTP POST 
message containing the order tracking identifier ('OTI"), and transmits the HTTP POST message to the order URL 

35 (uniquely identifying the internet address of the selling merchant) associated with the product (or products) purchased. 
A merchant site receiving an HTTP POST message which inckides an OTI determines the status of the order (e.g.. 



wo 98/21679 PCTAJS97/20624 
-31- 

"SHIPPED," "CANCELED," "WAITING FOR INVENTORY," etc.). The merchant site transmits an HTML document to 
the Web browser which includes the status information. The Web browser of the user computer displays the status 
information on the screen of the user computer. 

A consumer receives on-line assistance lor help) in using a computer-based shopping system by selecting 
5 a HELP option. In one embodiment, the HELP option is included in the HTML coding of a Web document and 
displayed to the user by a Web browser. Selecting the HELP option causes the Web browser 120 to access a HELP 
Web site. 

In another embodiment, the HELP option is displayed to the user by the user interface of the commerce 
client 122. Selecting the HELP option in this embodiment causes the commerce client 122 to establish a TCP/IP 

10 communication link to another computer if such a M is not already established. The commerce client 122 transmits 
an HTTP POST message directly to a HELP Web site. The commerce client 122 causes the Web browser 120 to 
begin running on the user computer if it is not already running. 

In either embodiment of the HELP option, the Web browser displays help information included in documents 
served by a Web server of the HELP Web site. The help information, for example, describes the use of the computer- 

15 based shopping system or the cause of errors encountered in operating the computer-based shopping syston, offers 
tips, or iDustrates features of the computer-based shopping system with pictures and diagrams. One skilled in the 
art will appreciete that on-line help couU alternetively be made available to consumers via a hierercbically ordered 
(topics, subtopics, and sub-subtopics) coDection of information residing on the consumer computer 102. 

A consumer conveniently accesses a merchant Web site 302 from which product information has been 

20 obtained by selecting the JUMP TO MERCHANT optnn. The user interfece of the commerce client inchides the 
JUMP TO MERCHANT option. By maintaining an association between a product name and a merchant Web site URL 
within the product data structure of every product, a computer-based shopping system locates a URL associated with 
the merchant selling a product hy accessing the product data structure for the product. The commerce client 122 
generates an HTTP POST massage accessing the merchant Web sita associated with the product. The merchant 

25 Web site responds by trensmitting an HTML document to the Web browser 120. Thus, the consumer conveniently 
accesses the Web site from which information about a product was obtained. 

A consumer terminates a computer-based shoppbig system by selecting an EXIT button. The EXIT button 
causes the commerce client 122 to write Knked in-memory data structures to a hard disk (other storage devices can 
suffice) in a manner which preserves the link relatnnships. The commerce cGent 122 then stops executing on the 

30 consumer computer 102. 

This invention may he embodied m other specific forms without departing from the essemial characteristics 
as described herein. The embodiments described above are to be considered in all respects as illustrative only and 
not restrictive in any manner. The scope of the invention is indicated by the foNowing clanns rather than by the 
foregoing description. Any and all changes which come within the meaning end range of equivalency of the claims 

35 are to be considered within their scope. 
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In the claims which follow, alphabetic characters used to designate claim steps are provided for convenience 
of description only, and are not intended to imply any particular order for performing the steps. 
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WHAT IS CLAIMED IS : 

1. A client architecture for conducting electronic coiranerce over the Internet, convrising, on a 
computer-readable medium: 

a Web browser application configured to run on a computer; 

a commerce client appOcation configured to run on the computer in conjunction with the Web 
browser application, the commerce client application including a callable function, said callable function 
comprising executable computer instructions stored on a computer storage medium accessible by the 
computer; 

an electronic shopping basket object configured to access and manipulate product information and 
merchant information stared on the computer storage medium, the access and manipubtion initiated by 
executing the callable function of the commerce client appEcation; and 

a Web document which inchides embedded function-calling mfonnation that corresponds to the 
callable function of the commerce cfient application, the function-calling information nnbedded within the 
Web document such that a user can selectively initiate the execution of the callable function while viewing 
the Web document with the Web browser. 

2. A client architecture for conducting electronic commerce over the Internet, 
comprising, on a computer-readable medium: 

a Web browser application configured to run on a computer; 

a commerce client application configured to run on the computer in 
conjimction with the Web browser application, the commerce client application 
including a callable function; 

an electronic shopping basket function configured to store product 
information and merchant information to a computer storage medium accessible by 
the computer, said electronic shopping basket fimction comprising executable 
computer instructions stored on a computer storage medium accessible by the 
computer, the product information and merchant information retrieved fi-om 
merchant Web sites over the Internet via the Web browser, the storing initiated by 
executing the callable function of the commerce client application; and 

a Web document which includes embedded function-calling information that 
corresponds to the callable function of the commerce client application, the 
function-calling information embedded within the Web document such that a user 
can selectively initiate the execution of the callable function while viewing the 
Web document with the Web browser. 
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3. A client architecture for conducting electronic conunerce over the Internet, 
comprising, on a computer-readable medium: 

a Web browser application configured to run on a computer; 

a conunerce client application configured to run on the computer in 
conjunction with the Web browser application, the commerce client application 
including a callable function; 

an electronic shopping basket function configured to retrieve product 
information and merchant information fi^m a computer storage medium accessible 
by the computer, said electronic shopping basket function comprising executable 
computer instructions stored on a computer storage medium accessible by the 
computer, the product information and merchant information obtained fi-om 
merchant Web sites over the Internet via the Web browser, the retrieval initiated 
by executing the callable function of the commerce client application; and 

a Web document which includes embedded function-calling information that 
corresponds to the callable function of the commerce client application, the 
function-calling information embedded within the Web document such that a user 
can selectively initiate the execution of the callable fiinction while viewing the 
Web document with the Web browser. 

4. The client architecture according to Claim 1, wherein the commerce client 
application includes a second callable function, and wherein the Web document includes 
embedded function-calling information that corresponds to the second callable function of 
the commerce client application, the execution of the second callable function selectively 
initiated by the user while viewing the Web document with the Web browser, the client 
architecture further comprising, on the computer-readable medium: 

an electronic wallet fimction configured to access and manipulate payment 
source information stored on the computer storage medium, the access and 
manipulation of the payment source information initiated by executing the second 
callable function of the commerce client application. 

5. The client architecture according to Claim 1, wherein the commerce client 
application includes a second callable function, and herein the Web document includes 
embedded function-calling information that corresponds to the second callable function of 
the commerce client application, the execution of the second callable function selectively 
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initiated by the user while viewing the Web document with the Web browser, the client 

architecture further comprising, on the computer-readable medium: 

an electronic address book object configured to access and manipulate 
shipping address information stored on the computer storage medium, the access 
and manipulation of the shipping address information performed by executing the 
second callable function of the commerce client application. 

6. A client architecture for purchasuig products over the Internet, comprising, 
on a computer-readable medium: 

a commerce client application configured to run on a computer, the 
commerce client application configured to transmit information to a World Wide 
Web site in accordance with World Wide Web protocols, the commerce client 
application configured to run in conjunction with a Web browser, the conunerce 
client application including a product purchase function which combines product 
information, merchant information, and payment source information and transmits 
the combined information to a World Wide Web site, the product purchase fiinction 
comprising executable computer instructions stored on the computer-readable 
medium. 

7. The client architecture according to Claim 6, fiirther comprising, on the 
computer-readable medium: 

a Web browser application configured to run on the computer; and 
a Web document which includes embedded function-calling information that 
corresponds to the product purchase function of the commerce client application, 
the function-calling information embedded within the Web document such that the 
user can selectively initiate the execution of the product purchase function while 
viewing the Web document with the Web browser. 

8. The client architecture according to Claim 7, fiirther comprising, on the 
computer-readable medium: 

an electronic shopping basket object configured to access and manipulate 
product information and merchant information stored on the computer storage 
medium, the electronic shopping basket fiinction transmitting product information 
and merchant information to the commerce client application during execution of 
the product purchase function of the commerce client application, the electronic 
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shopping basket object comprising executable computer instructions stored on the 
computer-readable medium. 

9. The chent architecture according to Claim 7, further comprising, on the 
computer readable medium: 

S an electronic wallet object configured to access and manipulate payment 

source information stored on a computer storage medium accessible by the 
computer, the electronic wallet object transmitting payment source information to 
the commerce client application during execution of the product purchase function 
of the commerce client application, the electronic wallet object comprising 
10 executable computer instructions stored on the computer-readable medium. 

10. A method for gathering product information over a distributed network, 
comprising: 

(a) sending a first hypolext document over the distributed network to a user 
computer, the first hypertext document comprising (i) a description of a first 

IS product, (ii) a user-selectable product gathering option, and (iii) function-calling 

information associated with the product gathering option; 

(b) displaying the first hypertext document to a user via the user computer 
and monitoring user input for selection of the product gathering option; and 

(c) responding to user selection of the product gathering option by calling 
20 an executable function specified by the function-calling information, the function 

storing the description of the first product to a local data storage area of the user 
computer. 

11. The method according to Claim 10 vHherein step (a) comprises sending an 
HTML document over the distributed network &om a Web server ruiming on a merchant 

25 Web site to a Web browser running on the user computer, the Web server in a location 
remote to the Web browser. 

12. The method according to Claim 10 wherein step (c) further comprises 
passing at least a portion of the fiinction-calling information fiom a Web browser to a 
local process running on the user computer, the local process calling the fimction. 

30 13. The method according to Claim 10, fiirther comprising the steps of: 

(d) sending a second hypertext document over the distributed network to the 
user computer, the second hypertext document comprising (i) a description of a 
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second product, (ii) a second selectable product gathering option, and (iii) function- 
calling information associated with the second product gathering option; 

(e) displaying the second hypertext document to the user via the user 
computer and monitoring user input for selection of the second product gathering 
option; 

(f) responding to user selection of the second product gathering option by 
calling a second executable function, the second function storing the description 
of the second product to the local data storage area; 

(g) displaying a product comparison option to the user via the user 
computer and monitoring user input for selection of the product comparison option; 
and 

(h) responding to user selection of the product comparison option by 
retrieving from the local storage area the description of the first product and the 
description of the second product, and by formatting the descriptions and 
displaying the descriptions to the user via the user computer. 

14. A method for purchasing a plurality of products from a plurality of 
merchants over a distributed network, comprising the steps: 

(a) storing on a computer storage medium a first network address 
corresponding to a first merchant and a second network address corresponding to 
a second merchant, the computer storage medium accessible by a user computer; 

(b) storing on the computer storage medium a first product identifier 
uniquely identifying a product of the first merchant and a second prodiict identifier 
uniquely identifying a product of the second merchant; 

(c) storing on the computer storage medium payment source data, the 
payment source data representing a source of credit or a source of funds; 

(d) displaying a product purchase option to a user via the user computer and 
monitoring user input for selection of the product purchase option; 

(e) responding to selection of the product purchase option by combining the 
first product identifier with the payment source data to generate a first payment 
instruction, and by combining the second product identifier with the payment 
source data to generate a second payment instruction; 

(f) transmitting the first payment instruction firom the user computer to the 
first network address over the distributed network; and 
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(g) transmitting the second payment instruction from the user computer to 
the second network address over the distributed network. 

15. A method according to Claim 14 wherein step (f) comprises encrypting the 
first payment instruction and transmitting the encrypted first payment instruction to the 

5 first network address, and wherein step (g) comprises encrypting the second payment 
instruction and transmitting the encrypted second payment instruction to the second 
network address. 

16. A method according to Claim 14 wherein the payment source data of step 
(c) is encrypted using an encryption password as a key, the encrypted payment source data 

10 not humanly readable, and wherein step (e) fiirther comprises prompting the user for entry 
of the encryption password and using the encryption password to decrypt the payment 
source data. 

17. A method for purchasing a plurality of products firom a merchant over a 
distributed network, comprising: 

15 (a) storing on a computer storage mediimi a network address corresponding 

to a merchant, the computer storage medium accessible to a user computer; 

(b) storing on the computer storage medium a product identifier uniquely 
identifying a product of the merchant; 

(c) storing on the storage medium a first quantity value representing a first 
20 quantity of the product and a second quantity value representing a second quantity 

of the product; 

(d) storing on the storage medium first and second encrypted payment 
source data, the first and second encrypted payment source data not humanly 
readable, the re^ective encryptions performed with user-entered fu^ and second 

25 payment soiirce passwords as encryption keys; 

(e) displaying a product purchase option to a user on the user computer and 
monitoring user input for selection of the product purchase option; 

(f) responding to selection of the product purchase option by prompting the 
user for the furst payment source password and the second payment source 

30 password; 

(g) monitoring user input for entry of the first and second payment source 
passwords; 
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(h) decrypting the first encrypted payment source data using the first 
payment source password and decrypting the second encrypted payment source 
data using the second payment source password; 

(i) combining the product identifier, the first quantity value, and the first 
payment source data to generate a first payment instruction; 

Q) encrypting the first payment instruction to generate a first encrypted 
payment instruction; 

(k) transmitting the first encrypted payment instruction to the network 
address; 

(1) combining the product identifier, the second quantity value, and the 
second payment source data to generate a second payment instruction; 

(m) encrypting the second payment instruction to generate a second 
encrypted payment instruction; and 

(n) transmitting the second encrypted payment instruction to the network 



18. A method in accordance with Claim 1 7 wherein the first payment instruction 
of step (1) is generated by combining the product identifier, the first quantity value, the 
first payment source data, and a first shipping address, and wherein the second payment 
instruction of step (1) is generated by combining the product identifier, the second quantity 
value, the second payment source data, and a second shipping address, the method 
comprising the further step of: 

(o) storing on the computer storage medium a first shipping address and a 
second shipping address. 

19. A method for using a Web browser to manage local data, the Web browser 
running on a user computer, the local data stored on a computer storage medium 
accessible by the user corapalbsr, the method comprising the steps of: 

(a) receiving with the Web browser an HTML document comprising a user- 
selectable view option and fiinction-calling information associated with the view 
option; 

(b) displaying the HTML document and the user-selectable view option to 
a user via the user computer; 

(c) monitoring user input for selection of the view option; and 
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(d) responding to selection of the view option by calling a view function 
specified in the function-calling information, the view function comprising 
executable computer instructions accessible by the computer, the view function 
accessing and formatting the local data and displaying the local data to the user. 

5 20. A method according to Claim 19 wherein the calling of the view function 

of step (d) is performed by sending a message which includes at least a portion of the 
function-calling information from the Web browser to a local Internet address representing 
the user computer, a local port-monitoring process monitoring the local Internet address 
and receiving the message, the local process using the fimction-calling information to 
10 make the function call. 

21. A method according to Claim 19 wherein the calling of the view fiinction 
of step (d) is performed by sending a message which includes at least a portion of the 
function-calling information from the Web browser to a local Internet address representing 
the user computer, a first local process monitoring the local Internet address and receiving 

15 the message, the first local process invoking a second local process if it is not ah«ady 
running, the first local process passing at least the function-calling information to the 
second local process, the second local process using the function-calling information to 
call the view fimction. 

22. A method according to Claim 19 wherein step (d) comprises responding to 
20 selection of the view option by calling a view function represented in the function-calling 

information, the view function accessing and formatting the local data and displaying the 
local data to the user, and the view function also displaying an add option to the user, the 
method further comprising the steps of: 

(e) monitoring user input for selection of the add option; 

25 (f) responding to selection of the add option by prompting the user to enter 

additional local data; 

(g) monitoring user input for entry of additional local data; and 

(h) responding to entry of additional local data by storing the additional 
local data on the computer storage medium. 

30 23. A method according to Claim 19 wherein step (d) comprises responding to 

selection of the view option by calling a view function represented in the fimction-calling 
information, the view fiinction accessing and formatting the local data and displaying the 
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local data to the user, and the view function also displaying an edit option to the user, the 
method comprising the further steps: 

(e) monitoring user input for selection of the edit option; 

(f) responding to selection of the edit option by prompting the user to select 
5 displayed local data; 

(g) monitoring user input for selection of displayed local data; 

(h) responding to selection of displayed local data by presenting the selected 
local data to the user for editing via the user computer and by displaying a done 
option; 

10 (i) applying edit operations performed by the user via the user computer to 

the selected local data to generate edited local data; 

(j) monitoring user input for selection of the done option; and 
(k) responding to selection of the done option by removing the selected 
local data from the computer storage medium and by storing the edited local data 
15 on the computer storage medium. 

24. A method according to Claim 19 wherein step (d) comprises responding to 
selection of the view option by calling a view function represented in the function-calling 
information, the view function accessing and formatting the local data and displaying the 
local data to the user, and the view function also displaying a delete option to the user, 

20 the method comprising the further steps: 

(e) monitoring user input for selection of the delete option; 

(f) responding to selection of the delete option by prompting the user to 
select displayed local data; 

(g) monitoring user input for selection of displayed local data; and 

25 (h) responding to selection of displayed local data by remoAong the selected 

local data from the computer storage medium. 

25. A method according to Claim 19 wherein the local data represent at least 
one source of credit or source of funds. 

26. A method according to Claim 19 wherein die local data represent at least 
30 one postal address. 

27. A method for tracking the status of a purchase order for a product over a 
distributed network, comprising: 
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(a) storing on a computer storage medium a network address corresponding 
to a merchant, the computer storage medium accessible to a user computer; 

(b) transmitting to the network address data comprising a purchase order, 
the data including a product identifier, a quantity value, payment source 

§ information, and shipping address ii^ormation; 

(c) receiving an order tracking identifier corresponding with the purchase 

order; 

(d) storing on the computer storage medium the order tracking identifier; 

(e) presenting an order status option to a user via the user computer; 
10 (f) monitoring user input for selection of the order status option; 

(g) responding to selection of the order status option by transmitting to the 
network address the order tracking identifier; 

(h) receiving order status information; and 

(I) displaying the order status information to the user via the user computer. 
15 28. A method in accordance with Claim 27 wherein the distributed network 

comprises the World Wide Web. 

29. A method in accordance with Claim 28 wherein the network address of step 
(a) identifies a Web site of the World Wide Web. 

30. A method in accordance with Claim 29 wherein the data transmitted in step 
20 (b) is formatted as an HTTP POST message. 

31. A method in accordance with Claim 28 wherein: 

step (c) comprises receiving via a Web browser a MIME message including 
an order tracking identifier corresponding with the purchase order, the MIME 
message passed to a local process; and 
25 step (d) comprises storing on the computer storage medium the order 

tracking identifier, the storing performed by instructions of the local process. 

32. A method in accordance with Claim 28 wherein the order status option of 
step (e) is included in an HTML-coded Web document, the order status option displayed 
to the user by a Web browser, the Web document including function-calling information 

30 associated with the order status option, and wherein: 

step (g) comprises responding to selection of the order status option by 
calling an order status function represented in the function-calling information 
included in the Web document, transmitting to the network address an HTTP POST 
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message including the order tracking identifier, the transmitting of the HTTP POST 
message performed by instructions of the order status fimction, the order status 
fiinction comprising executable computer instructions stored on the computer 



5 step (h) comprises receiving with the Web browser a second HTML-coded 

Web document including order status information; and 

step (i) comprises displaying the order status information to the user via the 
Web browser. 

33. A method for using a computer to access and display information, the method 
10 comprising the following steps: 

(a) establishing a communication link between the computer and a second 
computer using TCP/IP protocol; 

(b) running a local process on the computer, the local process displaying an 
information access option, the local process incapable of scanning an HTML file 

15 to generate a display on the computer screen; 

(c) monitoring user input for selection of the information access option; 

(d) responding to selection of the information access option by transmitting 
to the second computer an HTTP POST message including an information access 
request, the transmission performed by instructions of the local process; 

20 (e) running a Web browser on the computer; 

(f) receiving an HTML file transmitted by the second computer; and 

(g) displaying via the Web browser, information included within the HTML 

file. 

34. A method according to Claim 33 wherein the information describes usage 
25 of the local process. 

35. A method according to Claim 33 wherein the information describes the 
cause of an error in using or running the local process. 
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SOURCES 



DISPLAY OPTIONS TO ADD. EDIT, 
DELETE. OR MAKE PREFFERED 
PAYMENT SOURCES 



PROMPT USER FOR PASSWORD AND 
USE PASSWORD TO DECRYPT BLOB 
FOR EDITING 



DISPLAY DIALOG BOX WITH FIELDS 
FOR CARD #. EXPIRE DATE, NAME, 
BILLING ADDRESS, AND BANK 



I USER MODIFIES FIELDS 



7p30 
70J2 



|USER ENTERS PASSWORD TWICE} 

I 70J4 

^ \J 



WRITE ENCRYPTED BLOB. 
ASSOCIATE WITH FRIENDLY NAME 



MAKE PREFFERED 



ASSOCIATE SELECTED FRIENDLY 
NAME WITH DEFAULT PAYMENT 
SOURCE 
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CONSUMER SELECTS 
VIEW ADDRESS BOOK 

I — n o 

I LOAD ADDRESS BOOK OBJECT | 



USE MAINTAINED ROOT POINTER TO 
LINKED SHIPPING ADDRESS STRUCTURES 
TO RETURN FRIENDLY NAME OF FIRST 
SHIPPING ADDRESS STRUCTURE 



TRAVERSE LINKED LIST OF SHIPPING 

ADDRESS STRUCTURES, PLACING 
FRIENDLY NAME OF EACH IN A LIST 
BOX 



DISPLAY DIALOG BOX WITH RELDS 
FOR STREET ADDRESS, CITY. STATE, 
ZIPCODE, COUNTRY, AND NAME 



I USER FILLS IN nELPS| 



I USER SELECTS OK TO SAVe] 
DELETE 



I CONFIRM OK T O DELETE | 



T 



[delete SHIPPING ADDRESS DATA| 



DISPLAY BROWSABLE LIST BOX OF 
FRIENDLY NAMES FOR SHIPPING 
ADDRESSES 



DISPLAY OPTIONS TO ADD, EDIT, 
DELETE, OR MAKE PREFFERED 
SHIPPING ADDRESSES 



DISPLAY DIALOG BOX WITH FIELDS 
FOR STREET ADDRESS, CITY, STATE. 
ZIPCODE, COUNTRY, AND MORE 



I USER FILLS IN FIELDs] 



[USER SELECTS OK TO SAVEj 
MAKE PREFFERED 



ASSOCIATE SELECTED FRIENDLY 
NAME WITH DEFAULT SHIPPING 
ADDRESS 
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CONSUMER SELECTS 
READY TO PAY 
BUTTON 



LOAD SHOPPING BASKET OPTION 

x.....-zt. 



USE MAINTAINED ROOT POINTER TO 
LINKED MERCHANT STRUCTURES 
TO TRAVERSE LINKED MERCHANT UST 
AND LINKED PRODUCT USTS AND 
RETURN FIRST UNPURCHASED 
PRODUCT 



I TRAN^RSE REMAINING MERCHANT 

I AND PRODUCT LINKED LISTS AND RETURN 

i data for all unpurchased products 
l L 



GENERATE LIST OF ALL UNPURCHASED 
PRODUCTS AND SORT BY MERCHANT 
AND BY PoymentFriendlyName 



DISPLAY UST OF UNPURCHASED 
PRODUCTS TO USER AND CONFIRM 
PURCHASE REQUEST 




UPDATE VIEWS | 



I SEND ORDER TO MERCHANT URL| 
-f2J4 



, -^END OF^ ^ 

NO (Products for^ 

vMERCHANT^ 
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SYSTEM AND METHOD FO R CONDUCTING COMMERCE - 
QVER A PISTMBUTEP NETWORK 
Priority 

5 This application claims priority from the provisional patent application 

No. 60/020,891 mailed June 28, 1996, titled, "SYSTEM AND METHOD FOR 
CONDUCTING COMMERCE OVER A DISTRIBUTED NETWORK" 
Background of the Invention 

Field nfthe Invention 

1 0 This invention relates to distributed computer networics such as the Internet More 

particularly, this invention relates to client-server software components for allowing 
consumers to purchase goods and services from merchants over a distributed network. 
Description of the Related Art 

Electronic shopping systems currently exist which allow users to remotely 

15 purchase goods and services from a variety of different on-line merchants over a 
distributed computer network such as the Internet. With systems of this type, the on-line 
merchants typically publish on-line catalogs which can be viewed interactively by the end 
users of the network using a personal computer. These catalogs include pictures, textual 
descriptions, and pricing information with respect to the products and/or services of the 

20 respective merchants, and typically include on-line forms for allowing users to return 
purchase orders to the merchants over the networic. In World Wide Web ("Web") based 
implementations, the on-line catalogs are in the form of hypertext documents which are 
hosted by the Web sites of the respective merchants, and the catalogs are accessed using a 
standard Web browser application which runs on the user computer. (A Web site is an 

25 Intemet-coimected computer or computer system which runs server software for serving 
information using the standard protocols of the World Wide Web.) In other 
implementations, the on-line catalogs may, for example, be hosted by a centralized 
computer of an on-line services network, such as MSN™, or by an Internet site which is 
accessed using a proprietary cUent application (such as the client application of eShop 

30 Inc.). 
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Summary of the Invention " 
Some computer-based shopping systems cunently exist which allow the user to 
selectively store product information (and various other types of "shopping-state" 
infomiation) for subsequent recall and use. This allows the user to rapidly bring up the 
5 information viewed during previous visits to the merchant site, and to essentially continue 
the shopping session where the user left off. Unfortunately, these systems generally store 
the product information on the server side only (e.g., on the mwchant Wd) site), and do 
not include the necessary client and server software components for allowing the user to 
selectively store the product information on the consumer computer. This deficiency in 
1 0 the software architectures of existing computer-based shopping systems imposes several 
limitations on consumers. First, it makes it difficult for the consumer to gather product 
information ftom multiple merchants into a common, local storage area. This, in turn, 
makes comparison shopping very difficult: the consumer generally cannot, without 
considerable inconvenience, compare like products (or services) from different on-line 
1 5 merchants. Second, because the information is typically retained by the merchant site for 
a limited period of time (typically a few days), the consumer is under a time constraint to 
make use of the stored product information. Moreover, many hundreds or thousands of 
requests by consumers to store product information on a merchant's site may degrade the 
merchant site's response time, and create other problems related to the heavy storage 
20 burden. 

Also, because existing computer-based shopping systems typically host most or 
all transaction options on the server side, the shopping experience often differs from 
merchant site to merchant site. Specifically, as the consumer moves from one merchant 
site to the next, the options presented to the consumer and the steps required to navigate 

25 and effectively use those options often differ significantly. Thus, to browse product 
information and purchase products and/or services offered by multiple merchants, 
consumers often must adapt to and leam the options offered by each merchant site. 

Another problem with existing computer-based shopping systems is that they 
often require user entry of purchase information and shipping information upon every 

30 purchase, or at least require consumers to identify themselves during each shopping 
session. These restrictions are time consuming, tedious, and bothersome. Further, 
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repeated entry of payment information or shipping information increases the hkelihooii 
that a consumer will mistakenly oiter incorrect informatioa 

The present invention addresses these and other problems witii existing electronic 
shopping systems. In accordance with the invention, an electronic shopping system is 
5 provided which makes use of the existing client and saver software components and 
protocols of the World Wide Web, and which adds various client-side ftmctionalily for 
allowing users to store, view, and process product information (gathered from merchant 
Web sites), payment information, and shipping infomiation on the user computer. The 
system includes a specialized client application (referred to as the "commerce client") 

10 which runs on the consumer computer in conjunction with a standard Web browser. The 
commerce client communicates with a specialized commerce server (which runs on the 
merchant Web site in conjunction with a Web server) using a bi-directional fimction 
calling protocol. Hypertext (HTML) catalog pages served by the merchant Web site, as 
well as "user interface" hypertext documents stored on the user computer, include 

1 5 embedded fiinction calls which can be selectively invoked by the consumer while viewing 
the hypertext pages with the Web browser. Using these embedded function calls, the user 
can perform actions such as: request pricing or inventory information on a particular 
product from the merchant Web site; selectively store product information within a client- 
side shopping basket; view the contents of the shopping basket; and transmit encrypted 

20 shipping and/or payment information (stored on the consumer computer) to the merchant 
Web site. 

In accordance with one aspect of the invention, there is thus provided a method 
for gathering and comparing product information over a distributed network. The method 
comprises the steps of (a) sending a first hypertext document over the distributed network 

25 to a user computer, the fust hypertext document comprising a description of (i) a first 
product, (ii) a selectable product gathering option, and (iii) fimction-calling information 
associated with the product gathering option; (b) displaying the first hypatext document 
to a user via the user computer and monitoring user input for selection of the product 
gathering option; and (c) responding to selection of the product gathering option by 

30 calling an executable function specified by the fimction-calling information, the fiinction 
storing the description of the first product to a data storage area accessible to the user 
computer. Another embodiment of this aspect preferably comprises the fiirther steps: (d) 
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sending a second hypertext document over the distributed network to the user computer, 
the second hypertext document comprising (i) a description of a second product, (ii) a 
selectable product gathering option, and (iii) fiinction-calling information associated with 
the product gathering option; (e) displaying the second hypertext document to the user via 
5 the user computer and monitoring user input for selection of the product gathering option; 
(f) responding to selection of the product gathering option by calling a second executable 
function represented in the function-calling information, the function storing the 
description of the second product to the data storage area; (g) displaying a product 
comparison option to the user via the user computer and monitoring user input for 
10 selection of the product comparison option; and (h) responding to selection of the product 
comparison option by retrieving fiom the local storage area the description of the first 
product and the description of the second product, and by formatting the descriptions and 
displaying the descriptions to the user via the user computer. 

Anodier aspect of the present invention is a method for using a Web browser to 
15 manage local data. The local data is stored on a computer storage medium accessible to 
the user computer. The method comprises the steps of: (a) receiving with the Web 
browser an HTML document (HyperText Markup Language) comprising a user- 
selectable view option and fiinction-calling information associated with the view option; 
(b) displaying the HTML document to a user via the user computer, the display including 
20 the view option; (c) monitoring user input for selection of the view option; and (d) 
responding to selection of the view option by calling a fimction represented in the 
fiinction-callmg infonnation, the fimction accessing and formatting the local data and 
displaying the local data to the user. 

Brief Description of the Drawings 
25 These and other features of flie invention are described below with reference to the 

drawings of a preferred embodiment of a computer-based shopping system, which is 
intended to illustiiate and not to limit the invention, and in which: 

Figure 1 illustrates a consumer computer conmiunicating with two merchant Web 
sites of the system in accordance with the present invention; 
30 Figure 2 illustrates a preferred protocol for transferring function call requests and 

responses between the consumer computer and a merchant Web site of the system using 
the HTTP messj^e stream between a standard Web browser and a Web server; 
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Figure 3 illustrates a preferred software architecture for the merchant Web sites of 
the system; 

Figure 4 illustrates a preferred software architecture for the consumer computers 
of the system; 

5 Figure 5 illustrates data structures accessed and manipulated by shopping basket, 

wallet, and address book objects on the consumer computer; 

Figure 6 illustrates the steps performed in adding information (served by a 
merchant Web site) about a product to the shopping basket object; 

Figure 7 illustrates the steps performed in viewing product information stored 
1 0 within the shopping basket; 

Figure 8 illustrates the steps performed in deleting a product fiom the shopping 

basket; 

Figure 9 illustrates steps performed in viewing details about a product from the 
electronic shopping basket; 
15 Figure 10 illustrates the steps performed in viewing and manipulating payment 

source data in the wallet object on the consumer computer, 

Figure 11 illustrates the steps performed in viewing and manipulating shipping 
address data in the address book object on the consumer computer; and 

Figure 12 illustrates the steps performed in purchasing selected products from 
20 merchant Web sites of the system over a distributed network. 

Detailed Description of the Preferred Embodiment 
The present invention concerns electronic shopping and provides the abihty to use 
a personal computer to compare and purchase products offered for sale via a distributed 
network. The invention is embodied within a computer-based shopping system which 
25 utilizes the existing protocols and components of the World Wide Web. The computer- 
based shopping syst^ is described in detail herein. 

In the preferred embodiment, the system includes a "commerce client" process 
which runs on a consumer's computer in conjunction with a standard Web browser. The 
commerce client conmiunicates over the Internet with a "commerce server" (using a bi- 
30 directional fimction calling protocol) executing on a merchant Web site. In a preferred 
embodiment, the commerce client includes fimctionality similar to that of a shopping 
basket, a wallet, and an address book, and the commerce server includes fimctionality for 
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providing a variety of commerce-related services (such as accessing or returning product 
information, calculating taxes, processing orders, etc.)- 

The commerce client and commerce server operate together to allow a consumer 
to gather product information fiom any number of merchants while the consumer's 
computer is connected to the Internet. The commerce client also permits the consumer to 
perform comparison shopping by reviewing product information gathered from various 
merchants. This product comparison can be performed by the consumer at any time (e.g., 
while off-line) and over any length of time, regardless of whether the consumer's 
computer is connected to the Internet. 

A user unfamiliar with the operation of a computer-based shopping system which 
embodies the present invention can access instructional information (or application help) 
by selecting a help option. The instructional information is stored on one or more 
HTML-coded Web documents which are retrieved and displayed according to the user's 
needs. 

A computer-based shopping system embodying the present invention permits a 
user to purchase products fix)m an on-line merchant. The consumer uses the commerce 
client to authorize payment, select a payment source, select a shipping address (none of 
which require netwo± connection) and also to place an order to the merchant for the 
selected product. A network coimection is established for the commerce client to 
communicate the order to the commerce server. The payment and shipping information is 
protected from third party discovery using encryption technology. 

The following sections and subsections describe the invention in more detail: 

A. Glossary of Terms and Acronyms 

B. Example Computer-Based Shopping Session 

C. Communication Between Commerce Client and Commerce Server 

D. Software Architecture of Merchant Web Site 

E. Software Architecture of Consumer Computer 
A. Glossary of Terms and Acronyms 

The following terms and acronyms are used throughout the detailed description: 
Intemet. A collection of intercoimected (public and/or private) networks that are 
linked together by a set of standard protocols (such as TCP/IP and HTTP) to form a 
global, distributed netwoi*. (While this term is intended to refer to what is now 
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commonly known as the Intemet, it is also intended to encompass variations which may 
be made in the future, including changes and additions to existing standard protocols.) 

World Wide Web ("Web")- Used herein to refer generally to both (i) a distributed 
collection of interlinked, user-viewable hypertext documents (commonly referred to as 

5 "Web documents" or "Web pages") that are accessible via the Intemet, and (ii) the client 
and server software components which provide user access to such documents using 
standaniized Intemet protocols. Currently, the primary standard protocol for allowing 
applications to locate and acquire Web documents is HTTP (discussed below), and the 
Web pages are encoded using HTML (also discussed below). However, the terms "Web" 

10 and "World Wide Web" are intended to encompass future markup languages and 
transport protocols which may be used in place of (or in addition to) HTML and HTTP. 

CUent-Server. A model of interaction in a distributed system in which a program 
at one site sends a request to a program at another site and waits for a response. The 
requesting program is called the "client," and the program which responds to the request 

15 is called the "server." In the context of the World Wide Web, the client is a "Web 
browser" (or simply "browser") which runs on a computer of a user; the program which 
responds to browser requests by serving Web pages is commonly referred to as a "Web 
server." 

TCP/IP (Transmission Control Protocol/Internet Protocol). A standard Intemet 
20 protocol (or set of protocols) which specifies how two computers exchange data over the 
Intemet. TCP/IP handles issues such as packetization, packet addressing, handshaking 
and error correction. For more information on TCP/IP, see Volumes I, II and III of 
Comer and Stevens, Intemetworicing with TCP/IP, Prentice Hall, Inc., ISBNs 0-13- 
468505-9 (vol. I), 0-13-125527-4 (vol. H), and 0-13-474222-2 (vol. III). 
25 HTML (HyperText Markup Language). A standard coding convention and set of 

codes for attaching presentation and linking attributes to informational content within 
documaits. (HTML 2.0 is currently the primary standard used for generating Web 
documents.) During a document authoring stage, the HTML codes (referred to as "tags") 
are embedded within the informational content of the document. When the Web 
30 document (or "HTML document") is subsequently transferred Scorn a Web server to a 
browser, the codes are interpreted by the browser and used to parse and display the 
document. In addition to specifymg how the Web browser is to display the document. 
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HTML tags can be used to create links to other Web documents (commonly referred to as 
"hyperlinks"). For more infomiation on HTML, see Ian S. Graham, The HTML Source 
Book, John Wiley and Sons, Inc., 1995 (ISBN 0471-1 1894-4). 

Port or Port Number: (Also referred to as "socket number.") In the context of the 

5 Internet, a numerical identifier (normally provided in conjunction with an IP address) 
which is used by TCP/IP to direct incoming data to a particular application. Certain ports 
have been reserved by the Intemet Assigned Number Authority (lANA) for certain 
applications. For example, port 80 is reserved for HTTP, and is used on Web sites to 
direct incoming traffic to a Wd) server. (See "URL" below.) 

10 URL (Uniform Resource Locator). A unique address which fully specifies the 

location of a file or other resource on the Intemet. The general format of a URL is 
protocol://machine address:port/path/filename. The port specification is optional, and if 
none is entered by the user, the browser defaults to the standard port for whatever service 
is specified as the protocol. For example, if HTTP is specified as the protocol, the 

15 browser will use the HTTP default port of 80. 

HTTP (Hypertext Transport Protocol). The standard World Wide Web client- 
server protocol used for the exchange of information (such as HTML documents, and 
client requests for such docimients) between a browser and a Web server. HTTP includes 
a number of different types of messages which can be sent from the client to the server to 

20 request different types of server actions. For example, a "GET" message, which has the 
format GET <URL>, causes the server to retum the document or file located at the 
specified URL. 

HTTP POST. A type of HTTP message which is used to request that the Web 
server accept information tmm the Web client. This infomiation may, for example, be in 
2S the form of a message to be posted to a newsgroup, or a database submission which is 
executed by a CGI script. (See "CGI" below.) 

MIME (Multipurpose Intemet Multimedia Extensions) Type. A file extension or 
attachment which specifies the type or format of the file (e.g., HTML, text, graphics, 
audio, etc.). MIME typing allows the Web browser to determine how to process a file 
30 that is received fi-om a Web server. For example, a file of MIME type HTML (extension 
".htm" or ".html") will be displayed by the browser, while a file of MIME type X-WAV 
(extension ".wav") will typically be passed to an audio player which can handle the 
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Microsoft WAV format. Standard Web browsers come pre-configured to handle popular 
MIME types. In addition, standard Wd> browsers can easily be configured by the user to 
handle new MIME types; this typically involves specifying the file extension of each new 
MIME type, and specifying the path and filename of the application (referred to as a 
5 "MIME handler") to which files of such type should be passed. 

Internet Firewall. A security system placed between the Internet and an 
organization's network (such as a LAN) to provide a barrier against security attacks. 
Internet firewalls typically operate by monitoring incoming and/or outgoing traffic 
to/fix)m the organization's network, and by allowing only certain types of messages to 

10 pass. For example, a firewall may be configured to allow the passage of all TCP/IP traffic 
addressed to port 80, and to block all other traffic. For more information of Internet 
Firewalls, see Chapman and Zwicky, Building Internet Firewalls, O'Reilly publishing, 
1995 (ISBN 1-56592-124-0). 

CGI (Common Gateway Interface). A standard interface which specifies how a 

15 Web server (or possibly another information server) launches and interacts with external 
programs (such as a database search engine) in response to requests fix>m clients. With 
CGI, the Web server can serve information which is stored in a format that is not readable 
by the client, and present such infonnation in the form of a client-readable Web page. A 
CGI program (called a "CGI script") may be invoked, for example, when a Web user fills 

20 out an on-screen form which specifies a database query. One disadvantage of CGI is that 
it generally requires the launching of a separate process for each client request received. 
For more infonnation on CGI, see Ian S. Graham, The HTML Source Book, John Wiley 
and Sons, Inc., 1995 (ISBN 0471-11894-4), pp. 231-278. 

ISAPI (Internet Server Application Program Interface). Microsoft's interface for 

25 allowing a Web server (or other infonnation server) to launch and interact with external 
programs in response to requests &om clients. ISAPI programs are in the form of 
dynamic link libraries (DLLs) which run in the same process space as the Web server. 
Thus, ISAPI performs a similar fimction to that of CGI, but without requiring the 
launching of a separate process. Documentation on ISAPI is available firom Microsoft 

30 Corporation as part of the Microsoft Internet Information Server Software Development 
kit. 
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B. Example Computer-Based Shopping Session " 
This section provides an illustration of a hypothetical computer-based shopping 
session wherein features of the present invention are used. Figure 1 illustrates a consumer 
computer 102, a first merchant site ("merchant site A") 104, and a second merchant site 

5 ("merchant site B") 106, each connected to the Internet and utilizing the World Wide Web 
("WWW") 108. Merchant site A 104 and merchant site B 106 host shopping-oriented 
transactions to advertise and sell products over the Internet. The consumer computer 102 
and merchant Web sites 104, 106 run client and server software applications which allow 
a consumer to browse product information advertised over the WWW, gather information 

10 about products and merchants, selectively store the product and merchant information in a 
client side database, compare product information fiom different merchants, and purchase 
products sold ova: the Intemet. 

The consumer computer 102 comprises a processing unit 1 10, a data storage area 
1 12, as well as a monitor 1 14, keyboard 1 16, and a mouse 1 1 8. A standard Web browser 

15 120 (such as, for example, Microsoft Intemet Explorer 2.0 or Netscape Navigator 2.0) and 
a specialized commerce client process 122 execute on the processing unit 110. 

Merchant site A 104 comprises a processing unit 124 and a data storage area 126. 
A standard Web server 128 (such as Microsoft Intemet Information Server 1.0) and a 
specialized commerce server 130 execute on the processing unit 124. Likewise, merchant 

20 site B comprises a processing unit 132 and a data storage area 134. A standard Web 
browser 136 executes on the processing unit 132, as does a specialized commerce server 
138. 

A consumer using the consumer computer 102 stores payment source information 
140 such as a credit card number, expiration date, and issuing bank to the storage area 

25 112. The consumer supplies a password in association with the payment source 
information. The password is used not only to prevent ftiture unauthorized accesses, but 
also to encrypt the payment source information. The payment source information 
represents prefened sources of cash and/or credit for purchasing products and/or services. 
The commerce client 122 writes encrypted payment source data to the data storage area 

30 112. After entering the payment source information once and verifying its accuracy, the 
information persists on the consumer computer 102 without requiring re-entry by the 
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consumer. The consumer designates one of the payment sources stored as the preferred 
payment soiirce. 

The consumer also stores shipping address information 142 to the storage area 
112 via the consumer computer 102. Shipping address information indicates preferred 
S destinations for delivery of products and includes, for example, a personal residence 
address, a P.O. Box, or a business address. Again, the commerce client 122 writes 
shipping address information 142 entered by the consumer to the storage area 112. After 
the preferred shipping destinations are entered, they need not be entered a second time. 
As done with the payment source data, the consumer designates one shipping address as 

1 0 the preferred shipping address. 

A consumer uses the consumer computer 102 to shop for products such as, for 
example, an audio compact disc, a downloadable software program, a rare coin, or a 
refrigerator, offered by merchants via the World Wide Web 108. Using the example of 
shopping for a refrigerator, the consumer uses the consumer computer 102 to establish a 

15 connection to the Internet and uses a Web browser to navigate World Wide Web 108 
sites. Connecting to the Internet and browsing the WWW is well known and the steps 
involved will not be further described. 

The consumer uses the Web browser 120 to access a merchant site A 104 on the 
WWW. The Web server 128 of merchant site A 104 responds to the access initiated by 

20 the consumer computer 102 by retrieving a first HTML document (i.e;, a collection of 
data encoded in compliance with the Hyper-Text Markup Language) fi-om the set of 
HTML documents 144, and by then transmitting the first HTML document to the Web 
browser 120 of the consumer computer 102. 

The Web browser 120 interprets the HTML document and creates on the monitor 

25 114 a ps^e-oriented representation of the document. The consumer views the document 
on the monitor 1 14. The document may, for example, present textual information to the 
consumer describing merchant site A 104 such as the nature of products offered and the 
forms of payment accepted in filling orders for the products. The consumer may, for 
example, discover that merchant site A offers refrigerators for sale and accepts VISA for 

30 payment. 

Generally, consumer-selectable options ("hypertext links") are also presented 
within the HTML document which, if selected by a consumer using the mouse 1 1 8 or the 
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keyboard 1 16, cause the consumer computer 102 to transmit requests to the Web server 
128 to retrieve and transmit additional HTML documents providmg related or more 
detailed information. The consumer navigates additional hypertext links and browses 
additional HTML documents summarizing features of refiigerators sold by merchant site 
5 A. 

The consumer decides that one of the refiigerators offered by merchant site A is 
well-suited to the consumer's needs. A number of attributes are presented to the 
consumer, each attribute capable of being set to one of a number of values. Thus, for 
example, the user sets a color attribute to "Egg Shell White," sets an indoor water spout 

10 attribute to "No," and an automatic ice-maker attribute to "Yes." The consumer then 
selects an option labeled, for example, "Add Item to Shopping Basket." The Web 
browser 120 directs a corresponding message to the commerce client 122 causing 
information about the selected merchant A refiigerator, including the attributes selected, 
to be stored in a gathered products database 148. (The protocols and software 

IS components which enable this type of operation to be performed are described in the 
following sections.) Such information includes, for example, a picture of the refiigerator, 
cubic foot capacity, temperature range, energy usage, manufacturer's warranty, price, the 
attributes set by the consumer, the URL of merchant site A, and also includes a preferred 
payment source and a preferred shipping address. The consumer then ends the shopping 

20 session with merchant site A either by accessing a different World Wide Web site or by 
directing the consumer computer 102 to terminate the network connection to the Internet. 

Two days later, the consumer, again having time to shop, directs the consumer 
computer 102 to connect to merchant site B via the Worid Wide Web. Merchant site B 
also offers refiigerators for sale. After navigating through HTML documents describing 

25 the features of the refiigerators sold by merchant site B, the consumer selects a 
refiigerator, sets the refiigerator attributes as desired, and invokes the "Add Item to 
Shopping Basket" option. The commands to accomplish this are the same as those 
required to add the information about the merchant site A refiigerator to the shopping 
basket. The commerce client 122 responds to the invoked option by adding information 

30 about the merchant site B refiigerator to the gathered products database 148. The 
consumer then terminates the shopping session with merchant site B 106. 
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Three weeks later, the consumer uses the consumer computer 102 to compare tEe 
infonnation about the merchant site A refrigerator and the merchant site B refrigerator. 
The consumer does not need to connect to the World Wide Web to compare the two 
refrigerators. The consumer invokes an option entitled, for example, "View Items in 
S Shopping Basket." The commerce client 122 extracts the information about the two 
refrigerators from the gathered products information 148, and formats the infonnation 
such that the consumer can view it on the monitor 114. After weighing the features, 
warranties, and prices of the two refrigerators, the consumer decides to purchase the 
merchant site A refrigerator. 

10 The consumer then authorizes access to the payment source and address 

information stored on the consumer computer by entering a password known only to the 
consumer. After the consumer enters the password, the commerce client 122 accesses the 
payment source infonnation 140, decrypts the information, combines it with information 
about the merchant A refrigerator to assemble a goods and services order ("GSO"). The 

1 5 GSO is then encrypted and included as part of an HTTP POST message which is sent to 
the URL of merchant A. Merchant A receives the message, decrypts it, processes the 
order, and ships the product to the consumer's specified shipping address. 

A few years after purchasing the refrigerator, the constmier examines a product 
purchasing history to determine, for example, whether the refrigerator is still under 

20 warranty. The electronic shopping basket retains a complete, browsable history of all 
products purchased. 

C. Communication Between Commerce Client and Commerce Server 

The present invention extends the fimctionality of the standard Web browser 120 
by adding shopping-related features, namely, a shopping basket in which product 

25 information can be gathered, a wallet in which sources of payment can be stored, and an 
address book in which shipping addresses can be recorded. The standard Web browser 
120, so extended, offers consumers an extremely convenient and consistent method of 
shopping for products over the World Wide Web. This section describes a method for a 
Web browser to call ftmctions on both its own local computer and also on a computer 

30 executing a Web server. Additionally, a method is described for allowing a Web server to 
call ftmctions on a computer executing a Web browser. 
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Figure 2 illustrates communication between a consumer computer 102 and a 
merchant computer 202. A consumer accesses a merchant computer 202 on the Internet 
204 via a consumer computer 102. The consumer computer 102 includes a standard Web 
browser 120, and the merchant computer 202 includes a Web server 128. The Web 
5 browser 120 and the Web server 128 use the HTTP protocol to communicate with each 
other over the Intemet. 

The Web sorver 128 running on the merchant computer 202 accesses a local store 
144 of HTML documents (also commonly referred to as "Web documents" or "Web 
pages"). When the Web browser 120 on the consumer computer 102 requests an HTML 
10 document, the Web server 128 retrieves the HTML document and transmits it to the Web 
browser 120 on the consumer computer 102 where it is viewed by the consumer. These 
documents typically include information about the merchant, as well as information about 
the products sold by the merchant (including pictures and descriptions of products and 
product prices). 

IS To provide more sophisticated shopping transactions between consumers and 

merchants, software dedicated to providing consumer-oriented shopping fimctions (the 
commerce client 122) executes on a consumer's computer, and software dedicated to 
providing merchant-oriented functions (the commerce server 130) executes on a merchant 
computer 202. One objective of the present invention is to provide both a commerce 

20 client 122 running on the consumer computer 102 which communicates directly with the 
Web browser 120, and a commerce server 130 running on the merchant computer 202 
which communicates directly with the Web server 128. 

The commerce client 122 and the commerce server 130 utilize the Internet-based 
communication between the Web browser 120 and the Web server 128 to communicate 

25 with each other. An extensible Web function-calling protocol ("WFCP") permits the 
commerce client 122 and the commCTce server 130 to pass functions calls to each other by 
embedding the fimction calls in data exchanged via the Intemet by the Web browser 120 
and the Web server 128. As illustrated in Figure 2, the Web function-calling protocol 
effectively "hmnels" fiinction-calling information (requests and responses) through an 

30 HTTP message stream (shown in dashed lines) between the standard Web browser 120 
and the Web server 128. One significant benefit of the use of HTTP is that it allows the 
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consumer computer 102 to communicate with merchant Web sites fiom behind Internet 
firewalls 214 which permit passage of HTTP traffic. 

The Web server 128 serves HTML documents which include embedded fiinction 
calling infomiation. This fimction calling information is embedded in a hidden form 
5 using standard HTML tags, and is provided in a predefined format (specified as part of 
the WFCP) that is recognized by both the commerce client 122 and the commerce server 
130. Generally, the embedded function calling information corresponds to consumer- 
selectable options (e.g., hyperlinks or buttons) within HTML documents to allow a 
consumer to initiate client-to-server function calls across the Intemet by selecting (with 
1 0 mouse or keyboard) transaction options. 

Figure 2 illustrates an HTML document 206 being displayed by the Web browser 
120. The HTML document 206 includes a consumer-selectable button 208 associated 
with a textual description (such as "buy," "update shopping basket," "retrieve price 
information," or "retrieve account information") of a corresponding action to be 
IS performed. When the consumer clicks on this button, corresponding fimction-calling 
information is passed across the Intemet as a standard HTTP POST message firom the 
consumer computer 1 02 to the merchant computer 202. 

The fimction calling information for making a corresponding function call 
typically includes the name of an object, an object interface, a method, and an argument 
20 list. If the button 208 activates a "Calculate Tax" option, the corresponding fimction- 
calling information associated with the button may, for example, include the text: 
OB JECT=MSTaxEngine. 1 
INTERFACE=ITaxCalculation 
METHOI>=CalculateTaxDue 
25 ARGS=aigUst 

This fimction-calling information is provided in the HTML document along with 
a target URL (of the merchant Web site 104, 106) such that an HTTP POST message 
containing the information will be sent to the URL if the consumer cUcks on the button 
208. One example of an HTML-coded form of the HTTP POST message is: 
30 <HTML> 

<!— WFCP FORMATTED CALL— > 

<FORM ACTION=http://www.merchant.com/mig.dll 
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METHOD="POST" 

ENCTYPE="application/x-www-fonn-urlencoded"> 
<INPUT type=*iddai name=OBJECT vaIue=MSTaxEngine. 1> 
<INPUT type=hidden name=INTERFACE vaIue^ITaxCaiculation> 
5 <INPUT type=hidden name=METHOD value=CalculateTaxDue> 

<INPUT type=hidden name=ARGS value=argiist> 
<INPUT type=subinit value="Calculate Sales Tax"> 
</FORM> 
<yHTML> 

10 Although the target URL in this example corresponds to the Web site that is the 

source of the HTML document, the target URL could be that of a different Web site. 

Thus, when the consumer clicks on the button 208, the Web browser 120 
generates an HTTP POST message coded using HTML and sends the HTTP POST 
message to the URL of the merchant Web site 104, 106. This message includes function- 

15 calling infonnation (object, interne, method and arguments) to invoke a method (i.e., a 
software callable procedure or fimction) of a method library 212 on the merchant 
computer. If multiple function calls were linked to the button 208, the HTTP POST 
message would include the function-calling infonnation for each such function call. 

Upon receipt of the HTTP POST message, the Web server 128 parses the 

20 message, invokes the commerce server 130 (if not already executing) and passes the 
function-calling information to the commerce server 130. The commerce server 130 then 
invokes the specified object, and passes the arguments to the specified method using the 
specified interface; the commerce server 130 thereby makes the function call on behalf of 
the commerce client 122. Depending upon the method called, the fimction call may, for 

25 example, involve a query of and/or an update to a merchant database. 

This fimction call will typically produce a response which must be communicated 
to the consumer computer 102. (In the context of electronic shopping, the response 
message may include, for example, price or inventory information for a particular 
product, or the result of a tax calculation requested by the consumer.) The response may 

30 include a fimction call or other information directed specifically to the commerce client 
122. The Web browser 120 receives all data transmitted fix)m the merchant computer 202 
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to the consumer computer 102. However, some of the data received by the Web browser 
120 is fiirther routed to the commwce client 122. 

The Web server 128 transmits data to the consumer computer 102 by first 
padcaging the data as a MIME mess^e and then sending the MIME message across the 
5 Internet from the Web server 128 to the Web browser 120. If the response message is in 
the form of an HTML response to be displayed by the Web browser 120, the MIME type 
of the message will be HTML. If, on the other hand, the response message is directed to 
the commerce client 122 (such as when the response includes non-HTML product 
information), the response message will be tagged with a MIME type which corresponds 
10 to the commerce client 122, causing the Web browser 120 to forward the message to the 
commerce client 122. 

In the preferred embodiment, the MIME type associated with the commerce client 
is "x-ishopper." The message generated on the server side may include information to 
call a fimction on the consumer computer 102, in which case the MIME message will 
15 include function-calling information. This server-to-client fimction-calling information 
specifies the object, method, interface, and arguments of the client-side fimction call and 
is specified within the MIME message using the same fonnat (illustrated above) as used 
for client-to-server fimction calls. 

Upon receiving a MIME message of type "x-ishopper," the Web browser 120 
20 strips off the MIME headers and passes the message to the commerce client 122. As 
described further below, the commerce client 122 acts as a MIME handler for messages 
of type "x-ishopper." The commerce client 122 then invokes the method indicated in the 
MIME message on the consumer computer 102 in the same maimer performed by the 
commerce server 130 on the merchant computer 202. 
25 Thus, using HTTP POST messages and MIME messages, fimction calls are 

placed on the merchant computer 202 by the consumer computer 102 and fimction calls 
are placed on the consumer computer 102 by the merchant computer 202. 
Advantageously, WFCP is not tied to any specific function or set of functions. Thus, new 
client-side and server-side fimctions can be added (and embedded within HTML 
30 documents) without modification to the existing function-calling components. The 
WFCP protocol is described in further detail in a copending patent application entitled 
SYSTEM AND METHOD FOR MAKING FUNCTION CALLS OVER A 
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DISTRIBUTED NETWORK, filed June 28, 1996, which is hereby incorporated by 
reference, in its entirety. 

A further advantage, however, is gained in providing the Web browser 120 with a 
method to invoke local functions on the consumer computer 102. Using the same HTTP 
5 POST message format, the Web browser 120 invokes local functions by specifying a 
URL address that resolves to a local port. Rather than addressing an HTTP POST 
message to a r^ote site on the Web by using a URL similar to 
"http://www.sporting_goods.com", the Web browser 120 directs the HTTP POST to the 
local consumer computer 102 by using the URL "127.0.0.1:100" (note that ";100" 

10 specifies local port 100). This method of directing an HTTP POST message to the local 
computer is facilitated by the local host service of the TCP/IP protocol stack. The URL 
"127.0.0.1" is a local loop-back address recognized by the local host service as 
identifying the local machine as the recipient of the message. 

A port listener process operates on the local machine 102 monitoring a designated 

1 5 port such as, for example, port 100. The port listener receives the HTTP POST message, 
parses the content, and passes function-calling data directly to the commerce client 122. 
Thus, local fimctions are invoked by selected options coded in and hosted by a Web 
document wherein function-calling information is associated with the selected options. 
This method for making local function calls fi-om a Web browser is described in further 

20 detail in a copending patent application entitled SYSTEM AND METHOD FOR 
MAKING FUNCTION CALLS FROM A WEB BROWSER TO A LOCAL 
APPLICATION, filed June 28, 1996, which is hereby incorporated by reference in its 
^tirety. 

It will be appreciated by those skilled in the art that specialized client and server 
25 processes provide substantial benefits in the context of computer-based shopping. For 
example, a meix:hant can conveniently store relatively static catalog information as 
HTML documents, while storing relatively dynamic product information (such as price 
and inventory) in a separate database (not shown in Figure 2) which is accessed by the 
commerce server 130. This product information may advantageously be stored and 
30 served in a format which is recognized only by the specialized commerce client 122 (as 
opposed to the standard Web browser 120). Because the commerce client 122 runs in 
conjunction with the Web browser 120, the commerce client 122 can readily store both 
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consumer-selected HTML (catalog) data from Web pages of merchants, and the 
associated non-HTML product information retrieved via client-to-server function calls. 

As noted above, because all information is passed via HTTP, the commerce client 
122 and commerce server 130 can advantageously communicate through Internet 
5 firewalls 214 which are typically configured to permit the passage of TCP/IP messages 
addressed to port 80 and which, for security reasons, are configured to block 
communications addressed to other ports. 

Although Figure 2 depicts a single Web server 128 interacting with a single 
commerce server 130, it will be recognized that other system configurations are possible. 
10 For example, multiple Web servers 128 could be provided (mnning on the same machine 
or on different machines) which interact with a single, shared commerce server 130; or, 
multiple commerce servers 130 could be provided which interact with a single Web 
server 128. 

D. Software Architecture of Merchant Web Site 

15 Figure 3 illustrates a preferred architecture of a merchant Web site 302 of the 

computer-based shopping system. As shown in Figure 3, the merchant Web site 302 
includes a merchant computer 202, a storage device 304 (corresponding in function to the 
storage device 144 of Figure 2), and an Intemet connection 306. Software operating on 
the merchant computer 202 includes a Web server 128, the commerce server 130, and a 

20 method library 308 (corresponding to the method library 210 of Figure 2). A collection 
of Web documents 310 is stored on the storage device 304 as are various merchant 
databases 312. 

The merchant Web site 302 may, for example, be a stand-alone site which 
independently serves information with respect to a single merchant, or may be in the form 

25 of (or a part of) a centralized or distributed electronic mall system which serves the 
information of many different marchants. The Web server 128 is preferably the Microsoft 
Litemet Information Server version 1.0, although other conventional Web servers can be 
used. The commerce server 130 is preferably in the form of an IS API (Intemet Server 
Application Program Interface) DLL (dynamic link library) which mns within the same 

30 process space as the Web server 128. A CGI script, or a DLL which uses another SCTver 
extension API (such as NS API firom Netscape), could alternatively be used. 
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The Web documents 310 stored on the merchant Web site 302 are preferably 
coded using HTML. The Wd) documents 310 contain HTML coding which, when 
received by a Web Browser 120, display various icons or buttons on the screen 1 14 of the 
consumer computer 102 along with text or pictures comprising the content of the Web 
S document. As described above, these icons or buttons comprise selectable options which 
correspond to shopping-related transactions. In the preferred embodiment, the Web 
documents 310 offer consumers options to add product information to an electronic 
shopping basket, view products collected but not yet purchased, view products already 
purchased, enter payment information into an electronic wallet, place shipping addresses 

10 in an electronic address book, as well as order goods torn Web-based merchants. These 
selectable options coded into the Web documents 310 have function-calling information 
associated with them (as described above) to invoke executable functions on the 
consumer computer 102 or back on the Web server 128 when selected. Web documents 
with embedded client-side function calls are also preferably stored on the hard disk of the 

1 5 consumer computer 1 02 as part of the user interface of the commerce client 1 30, allowing 
the user to invoke client-side functions (such as viewing the shopping basket) while off- 
line. 

The method library 308 of the merchant Web site includes methods for 
performing client services such as retrieval of product information, calculation of sales 
20 taxes, and capture of orders. Some of these methods are listed and described in Table 1 . 



Method 


Description 11 


GetLineltem 


Retrieves product information given SKU (stock keqping unit) 11 
number or other product identifier. 


GetPrice 


Retrieves price information given SKU number or other product 
idoitifier. 


CalculateSH 


Calculates shipping and handling costs given product/s and 
shipping logistics (e.g., shipping address and method). 


CalculateTaxDue 


Calculates shipping and handling costs given product/s and 11 
shipping logistics 


ProcessOrder 


Captures order submitted by consumer, and processes in a manner 11 
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Method 


Description 




specified by merchant. 



TABLE 1 



The commerce server 130 performs two primary tasks. First, when a request is 
received for product information (via fimction-calling infonnation embedded within an 
HTTP POST message received by the Web server 128), the commerce server retrieves 
5 various data items in connection with a product, such as SKU (stock keeping unit) 
number, product name, product description, logo, price, expiration date, tax, and shipping 
charges. This data is packaged as a MIME file of type "x-ishopper" and sent back to the 
consumer computer 102 via the Web browser 120, as described above. Second, the 
commerce server 130 captures and processes orders for products submitted by consumers. 

10 In accordance with the present invention, the merchant sites of the system prepare 

and serve HTML Web documents 310 which present uniform transaction options, such as 
View Shopping Basket, Show Wallet, and Initiate Payment. 

Due to the wide variety of inventory management systems and legacy (long- 
existing and difficult to change) product information databases, as well as accounts 

15 receivable systems, the commerce server will often comprise custom interface software 
that will change &am merchant to merchant. The present invention is primarily 
concerned with the consumer platform. 
E. Software Architecture of Consumer Computer 

Figure 4 illustrates the software architecture of the consumer computer 102. The 
20 architecture comprises a conventional Web browser 120 (such as Microsoft's Internet 
Explorer 2.0, or Netscape Navigator 2.0), the commerce client 122, and a commerce 
clirait object library 402, and a storage area 1 12. The conmierce client object library 402 
comprises a shopping basket object 404 having associated shopping basket methods 406, 
a wallet object 408 having associated wallet methods 410, and an address book object 412 
25 having associated address book methods 414. The storage area 112 comprises merchant 
information 416, product information 418, payment source data 140, and shipping address 
data 142, all of which has been selectively stored and/or manually entered by the user. 

The Web browser 120 is preferably configured such that the commerce cliait 122 
is a MIME-handler application. Generally, a MIME-handler is a software application 



SUBSTITUTE SHEET (RULE 26) 



wo 98^1679 PCT/nS97/20fi24 
22 

designed to provide specialized processing of specific types of files received over tKe 
Internet by a Web browser 120. The Web browser 120 of the present invention is 
configured to associate the MIME type "x-ishopper" with a certain file name extension 
such as "ish." When the Web browser 120 receives a file of type "x-ishopper," the Web 
5 browser will cause the commerce client 1 22 application to begin executing (if not already 
running). The Web browser 120 will then pass the received "x-ishopper" file to the 
commerce client 122 for fijrther processing. Extending the fimctionality of a Web 
browser by configuring the Web browser to associate specific file types with file name 
extensions and then associating specialized MIME-handler applications with file name 

1 0 extensions is well known and will not be fiirther discussed herein. 

The commerce client 122 executes on the consumer computer 102 as a separate 
process fi-om the Web browser 120 and is a standard executable program. The commerce 
client 122 begins executing when launched by the Web browser 120 upon the Web 
browser's receipt of a file of MIME type "x-ishopper." Another way in which the 

15 commerce client 122 begins executing is when a local port listener task receives a 
message fi»m the Web browser 120 which was directed at a local port. The port listener 
launches the commerce client 122 if it is not aheady executing. 

Still another way of launching the commerce client 122 is by running the 
commerce client program directly. As explained below in more detail, many fiinctions 

20 ("local" fiinctions) of the commerce client 122 do not require an Internet connection or 
transmission of data to or fi-om a Web site. These local fiinctions are available via user- 
interface HTML documents which reside on the consumer computer's hard disk. The 
commerce client 122 executes until the consumer selects an option causing the commerce 
client 122 to stop executing. 

25 When the commerce cliait 122 starts running, it performs an initial task of 

loading structures in memory from data stored on the hard disk or other fixed storage 
media. The data represent merchant information, product information, payment source 
information, and shipping addresses. The data are stored in such a way as to be easily 
read into memory while maintaining relationships (links) among the data. Such 

30 construction of interlinked in-memory structures from data stored on a hard disk is well 
known in the art. When the commerce client 122 shuts down or otherwise terminates 
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nonnally, it writes the interlinked in-memory structures to hard disk storage in a manner 
that preserves all the relationships among the data. 

The data comprismg the in-memory data structures are accessed and manipulated 
through objects. The shopping basket object 404 is associated with shopping basket 
5 methods 406 which read, write, modify, and display information about merchants and/or 
products of interest to the consumer. The shopping basket methods 406 interact primarily 
with in-memory structures comprising product and merchant information. In accordance 
with the present invention, data for each product are preferably organized into groups as 
shown in Table 2. 



Product Data Field 


Description 


Logo 


Picture associated with product 
1 ypc. V \jiu 


LogoSize 


Size of Picture associated with product. 
Tvn<»' nwrfl?r> 

lypc. uwKjptSJ 


Name 


Name of product. 
Type; Cstring 


Description 


Description of product. 
Type: Cstring 


Price 


Unit Price of product. 

Type: Currency 


Quantity 


Quantity of product to order. 
Type: Float 


ExpirationDate 


Date on which offered price expires. 
Type: Cstring 


Tax 


Amount of tax computed for sale of product. 
Type: Currency 


ShippingCharge 


Cost to ship product as ordered. 
Type: Currency 


OttierCharges 


Miscellaneous additional charges associated with order. 
Type: Currraicy 
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Product Data Field 


Description 


SKU 


Stock Keeping Unit, merchant's identifier for product 
Type: Cstring 


ShipMethod 


Delivery services to be used in shipping product. 
Type: Cstring 


OrderURL 


URL string identifying Web site to send order for product 
Type: Cstring 


ReferenceURL 


URL string identifying Web site for information about the 

product 

Type: Cstring 


PaymentFriendlyNamc 


Reference to entry in Payment Database identifying source of 
payment if product is ordered (e.g., Visa, Checking Acct., 
etc.) 

Type: CString 


AddressFriendlyName 


Entry in Shipping Address DB identifying where to ship 

product 

Type: CString 


Flags 


0 if product has not been purchased; 1 if product has been 

purchased 

Type: DWORD 



TABLE 2 

There may be a variety of properties associated with a product which are unique to 
that product and are not associated with other products. Such properties are represented 
in name/value pairs in memory and can be referenced fix)m an in-memory product 
structure through an associated pointer to a linked list of such properties. The property 
data are organized as shown in Table 3. 

Description 
Name of property 
Type: Cstring 
Value of property 
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Type: Variant 


Flags 


Stores various flag values 
Type: DWORD 


TABLE 3 

Merchant data preferably comprise associated fields as shown in Table 4. 


Merchant Data Field 


Description 


Logo 


Logo associated with merchant 
Type: VOID* 


Logosize 


Size of logo associated with merchant. 
Type: DWORD 


Name 


Name of merchant. 
Type: Cstring 


LineltemList 


Pointer to linked list of product data structures 
Type: Pointer 



TABLE 4 



The wallet object 408 is associated with wallet methods 410 which provide access 
5 to payment source data (such as credit card numbers and checking account numbers) used 
for making on-line purchases. Payment source data are stored in memory preferably 
according to associated fields as shown in Table 5. 



Payment Data Field 


Description 


FriendlyName 


Easily remembered and recognized name for payment source 
Type: Cstring 


1 CardNumber 


Credit card or account number 

Type: Cstring 


ExpirationDate 


Date on which credit card expires. 
Type: Cstring 


CustomerName 


Name of card holder or account holder | 
Type: Cstring j 


IssuingBank 


Name of bank issuing credit card or account 
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Type: Cstring 


BillToAddress- 
FriendlyName 


Reference to address database indicating address to be billed 
when payment source is used to order product. 
Type: Cstring 


TABLES 

The address book object 412 is associated with address book methods 414 which 
access addiess information for shipping purposes. The address book methods 414 access 
address data preferably organized as shown in Table 6. 




Dcscripti on 


FriendlyName 


Easily remembered and recognized name for addresses 
Type: Cstring 


Name 


Name of person to receive parcels at address 
Type: Cstring 


Address 1 


First text line of shipping address. 
Type: Cstring 


AddressZ 


Second text line of shipping address 
Type: Cstring 


Address3 


Third text line of shipping address 
Type: Cstring 


City 


Name of city of shipping address 
Type: Cstring 


State 


Name of state of shipping address 
Type: Cstring 


Zip 


Zip code of shipping address 
Type: Cstring 


Country 


Name of country of shipping address 
Type: Cstring 


Phonel 


First phone number associated with shipping address 
Type: Cstring 


Phone2 


Second phone number associated with shipping address 
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II I Type: Cstring || 

TABLE 6 

The shopping basket object 404, wallet object 408, and address book object 412 
are preferably implemented as in-proc^s COM (component object model) compliant 
objects, implemented as a single DLL (dynamic link library). The component object 
5 model is well-understood in the art and will not be fiirther discussed. One skilled in the art 
will, however, appreciate that callable functions with appropriate associated data 
structures could be used in place of the shopping basket object 404, the wallet object 408, 
and the address book object 412 and their respective associated methods 406, 410, 414. 

Figure 5 illustrates generally the type of data accessed by the primary objects of 

10 the commerce client. A shopping basket object 502 accesses and manipulates merchant 
data structures 504, product data structures 506, and product property data structures 508. 
A wallet object 510 accesses and manipulates payment source data structures 512. An 
address book object 514 accesses and manipulates address book data structures 516. 

As described above, the commerce client 120 responds to various function-calling 

15 infonnation embedded in MIME files of type "x-ishopper" passed from the Web Server 
128 through the Web browser 120, and also responds to function-calling information 
received indirectly from the Web browser 120 by way of a local port to which the Web 
browser directs data meant for the commerce client 122. The function-calling 
information identifies objects and methods which the commerce cUent 122 invokes. 

20 When viewing a Web document 310 which, for example, describes a product 

(hosts an item) and which is coded according to the present invention, the standard Web 
browser displays an ADD ITEM-type option to the consumer which allows infonnation 
about a product to be stored in the electronic shopping basket (in computer memory, and 
eventually written to a hard disk). The ADD ITEM option can be selected, for example, 

25 when the consumer has interest in the product, even if the consumer has not yet decided 
to purdiase the product. The Web document 310 will also typically include a product 
form which is displayed on the consumer's computer screen. The product form 
represents a number of attributes which can be set by the consumer by filling in values. 
After setting attributes as desired (e.g., selecting a size or color for the product), the 

30 consumer selects the ADD ITEM option to store such "usct preference" attributes along 
with the information provided by the merchant. 
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Figure 6 illustrates the stq)s perfoimed when a consumer selects the ADD IT^ 
option. In a first step 602 the Web browser 120 issues an HTTP POST message to the 
Web server 128 indicating that a consumer has selected an ADD ITEM option. In a next 
step 604, the Web s^er 128 retrieves product information fiom the merchant web site 
5 and sends the information to the Web browser 120 as a MIME message of type "x- 
ishopper." Next, in a step 606, the Web browser 120, after establishing receipt of a 
MIME message of type x-ishopper, launches the commerce client 122 (if it is not already 
running). The commerce client, in a step 608, constructs an in-memory representation of 
merchant, product, payment, and address data read from a hard disk. Then, in a step 610, 

10 the Web browser 1 20 passes the MIME message to the commerce client 1 22. 

The commerce client 122 uses function-calling information embedded in the 
passed MIME message to call a method AddLineltem. In the step 612, the AddLineltem 
method navigates memory structures (constructed in step 608) looking for a merchant 
data structure with a name field matching the merchant name passed with the MIME 

IS message. If no such merchant structure is found in the step 612, then a new merchant 
structure is appended to the linked list of merchants by allocating memory and the new 
merchant structure is populated with merchant data fix>m the passed MIME message. The 
AddLineltem method then, in a next step 614, navigates a linked list of product data 
structures associated with the merchant stmcture (either foiuid or created in the step 612). 

20 Each product data structure in die list represents one product offered for sale by a 
merchant. In the step 616, the AddLineltem method allocates memory for a new product 
data structure and populates it with data packaged in the MIME message such as product 
SKU, price, quantity, description, name, logo, color, or size. The AddLineltem method 
then links the new product data structure to the end of the linked product data structures 

25 for the merchant 

In a step 618, the commerce client 122 invokes a SetltemProperty method 
wherein the linked list of merchant structures is again navigated until a merchant structure 
having a merchant name matching the passed mochant name is found. In a step 620, the 
product data structures referenced by the merchant structure are navigated until a product 

30 data structure is found having an SKU field equivalent to the SKU number passed in the 
MIME message. Ihen, in the step 622, the SetltemProperty method navigates a linked 
list of properties referenced by the product data structure found, and does so for each 
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property passed in the MIME message. When a property structure is found whose name 
matches the passed property name, the value associated with the matched property name 
is rq>laced with a value passed in connection with the property name. In each case where 
the property list is navigated and no matching property name is found, the 
5 SetltemProperty method appends a new property data structure to the linked list of 
properties. The SetltemProperty method allocates memory for the new property data 
structure and fills in the name and value and flag fields as appropriate from the data in the 
passed MIME message. 

In a step 624, the commerce client 122 then executes the steps comprising the 

10 VIEW SHOPPING BASKET option described below. Thus, when the steps comprising 
the ADD ITEM option are completed, a new product data structure is stored in memory 
comprising data fields such as SKU, price, quantity, picture, description, reference URL, 
and merchant information. Also, any special properties associated with the product such 
as size, color, or finish, are also stored with the new product data structure. As explained 

IS below, default payment source information and default shipping address information are 
also associated with a new product data structure. 

Web documents 310 served by Merchant Web sites and/or stored locally on the 
consumer computer 102 offer consumers a selectable option called VIEW SHOPPING 
BASKET. This option allows consumers to retrieve a list of all the products that have 

20 been placed inside the electronic shopping basket using the ADD ITEM option. 

Figure 7 illustrates the steps in carrying out the VIEW SHOPPING BASKET 
option. In a first step 702, the consumer selects the VIEW SHOPPING BASKET option 
fix)m within the Web browser. In a next step 704, the Web browser 120 issues a local 
function call. Then, in a step 706, the commerce client 122 is launched (if not already 

25 executing) by a local port monitor detecting the local function call. Next, in a step 708, 
the commerce client 122 loads the shopping basket COM object. In a next step 710, a 
variable CheckFlag is set equal to 0. Then, in a step 712, a loop is entered and is executed 
once for each merchant data structure. 

In a step 714, the commerce client 122 invokes a GetFirstltem method. In the 

30 step 714, the GetFirstltem method navigates to a given marhant. In this first iteration of 
the loop, the given merchant will simply be the first merchant in the merchant data 
structure list In the step 71 6, the linked list of product data structures referenced fixjm the 
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first merchant data structure is navigated to the first product data structure. If, in the st^ 
718, it is determined that there are no product data structures for this merchant or the 
navigation of the product data structure list has reached the end of the list, then, in a stqi 
720, the GetFirstltem method returns a value of 0. If in the step 7 1 8 it is determined that 
5 another product data structure exists and that the end of the product data structure list has 
not yet been reached, then the flag field of the product data structure is compared against 
the CheckFlag variable. Because CheckFlag is equal to 0, the product flag is being 
compared against the value 0 which would indicate that the product has not yet been 
purchased. If in the step 722, it is determined that the product flag is not equal to the 

10 CheckFlag then processing reverts back to the step 716 to check the next product data 
structure in the list. If, however, in the step 722, the product flag is equal to the 
CheckFlag, indicating that the product has not yet been purchased, then in a step 724, a 
pointer is returned pointing to the product data structure of the product that has not been 
purchased and the name of the product that has not been purchased is added to a Ust box 

15 structure. Next, in a step 726 the pointer to the product data structure is saved and 
iterations of the loop are terminated. 

In the step 728, the GetNextttem method is invoked which begins by navigating 
to a given merchant. In the step 730, a current chain of linked product data structures is 
navigated to a point equal to a saved pointer location (the pointer location saved in step 

20 726 if this invocation of GetNextltem immediately follows the termination of the 
GetFirstltem method, otherwise the pointer location saved in the step 742 is used). Next, 
in the step 732, the next product data structure in the linked list is examined. If in the step 
734 it is detamined that the end of the product data structure list has been reached then in 
the step 736, a 0 is returned. If, however, in the step 734 it is determined that the end of 

25 the product data structure list has not yet been reached then, in the step 738, the product 
flag is compared against the CheckFlag. If in the step 738 the product flag is not equal to 
the CheckFlag then processing resumes in the step 732 examining the next product data 
structure in the list. If, however, in the step 738 the product flat is equal to the CheckFlag 
then, in the step 740, a pointer is retumed to the product data structure and the name of 

30 the product is added to the list box structure. Next, in the step 742, a pointer to the 
product data structure is saved. The GetNextltem method is then invoked again 
beginning at step 728 where the list of merchant data structures is navigated to the current 
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merchant and the steps 728 through 742 are repeated until the end of the merchant data 
structure is reached. 

When, in a step 744, the end of the merchant data structure list is reached, then in 
a step 746 a scrollable list of product names appears on the consumer's computer screen. 
S The list of product names corresponds to all products currently in the electronic shopping 
basket which have not yet been purchased. 

Web documents 310 also offer consumers a VIEW HISTORY option. By 
selecting VIEW HISTORY, a list of product names is displayed on the user computer, all 
of which have been purchased. In one embodiment, the steps illustrated in Figure 7 in 

10 relation to the VIEW SHOPPING BASKET option are all performed in relation to the 
VIEW HISTORY option with one exception. In performing the VIEW HISTORY 
option, the CheckFlag variable in the step 710 is set equal to 1 instead of 0. Thus 
modified, the steps detect all product data stmctures whose flags are set to 1 indicating 
that they have already been purchased. The steps of Figure 7 then construct a list of 

1 S product names reflecting all of the products that have been purchased. 

In another embodiment, selecting the VIEW HISTORY option causes a list of all 
product orders to be displayed. Each merchant structure has a reference pointer to a list of 
order structures. Each order stmcture, in addition to having fields for payment, shipping, 
and order tracking information, also has a reference pointer to a list of product structures. 

20 Thus, the linked list of merchants is traversed. For each merchant, the respective 
merchant's list of order structures is traversed. One display item is generated from each 
order structure. Each display item shows on the screen of the user computer, the purchase 
date, the payment information, the shipping address, the order tracking identifier, and the 
products ordered. Note, the products ordered are determined by traversing the linked list 

25 of product structures associated with each order structure. The VIEW HISTORY option 
advantageously allows consumers to gamine past purchases whether such purchases 
occurred very recently or many years ago. 

The VIEW SHOPPING BASKET and VIEW HISTORY options do not require a 
connection to the Intemet to operate. In addition, these functions can optionally be 

30 invoked without using the Web browser. To perform these functions without a Web 
browser 120, the consumer initiates execution of the commerce client 122 by, for 
example, using a mouse and double-clicking an icon present on a graphical user interface 
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of the consumer computer 102 (an icon with which the commerce client 122 executable 
program is associated). A commerce client user interface offers consumers a selection of 
options which do not require a coimection to the Internet. These options are noted below 
to distinguish them from options which require Web-based communication. 
5 Web documrats 310 of the system may also host a DELETE ITEM option to 

remove an item from the electronic shopping basket. Figure 8 illustrates the steps 
performed to carry out the DELETE ITEM option. In a first step 802, the consumer 
selects the VIEW SHOPPING BASKET option and is presented with a list of products 
which have been gathered but which have not been purchased. The DELETE ITEM 
1 0 option is then presented. 

In a next step, 804, the consumer selects a product name from the list. Then, in a 
step 806, the consumer either selects the DELETE ITEM button or presses the delete key 
of the keyboard. The consumer is then prompted to confirm the deletion in a stq> 808. If 
the consumer does not confirm the deletion in the stq) 808, then, in a step 810, the steps 
15 of Figure 8 terminate. If, however, in the step 808, the consumer does confirm the 
deletion, then the DeleteLineltem method is invoked. 

A next step 812 then uses a pointer to the product data structure of the selected 
product to locate the preceding product data structure in a linked Hst. Locating a 
preceding structure in linked list is preferably done by implementing the list as a double 
20 hnked list (one whose structures point both to the next stracture as well as the preceding 
structure). It is possible that there is no preceding product data structure, that is, that the 
product data structure for the selected product is the first in the list of such product data 
structures that is referenced by a merchant data structure. In any case, a pointer to the 
product data structure will be located, it will simply belong to a merchant data structure 
25 rather than to a preceding product data structure. 

In a step 8 14, the same pointer to the product data structure of the selected product 
is used to locate a following product data stmcture (i.e., one which follows the product 
data stmcture corresponding to the selected product). It is possible that there is no 
following product data structure or, in other words, the product data stracture of the 
30 selected product has a NULL pointer to the next product data structure. 

Finally, in a step 816, the pointer located in the step 812 (i.e., the pointer which 
points to the product data structure of the selected product) is set to point to the product 
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data structure which follows the product data structure of the selected product. In the case 
where there is no product data structure following the product data structure of the 
selected product, then the pointer located in the step 812 is simply set to NULL. Thus, 
the product data structure of the selected product is no longer referenced (is delinked) 
5 ftom the in-memory data structures and is effectively deleted. The DELETE ITEM 
option is ofTered to consumers via the commerce client user interface as well as on Web 
documents displayed by the Web browser 120. 

Another option that is presented to a consumer following selection of the VIEW 
SHOPPING BASKET option, is an option to SEE ITEM DETAILS. The SEE ITEM 

10 DETAILS option allows a consumer to check the value of the unique properties of a 
product (e.g., a selected color or size) as well as the payment source to be used in 
connection with a purchase and also the address the product is to be shipped to if ordered. 

Figure 9 illustrates the steps performed in relation to the SEE ITEM DETAILS 
option. First, in a step 902, the consumer selects the VIEW SHOPPING BASKET button 

15 and is presented with a list of products. In a next step, 904, the consumer, selects a 
product name from the list. Then, in a step 906, the consumer selects the SEE ITEM 
DETAILS button. 

The Web browser 120 then, in a step 908, sends a local HTTP POST message 
directed to a local port. A port listener responds to the message in a step 910, and 

20 forwards the message to the commerce client 122 in a step 912. 

In a step 914, the commerce client 122 uses a pointer to the product data structure 
of the selected product (this pointer is maintained following the selection of the product in 
connection with the VIEW SHOPPING BASKET option) to conveniently locate the 
product data structure of the product selected. Next, in a stqj 916, a drop-dovirn box is 

25 created having the Friendly Name of a payment source (i.e., the value associated with the 
PaymentFriendlyName field of the product data structure) as the only entry. Similarly, in 
a step 918, a second drop-down box is created having the Friendly Name of a shipping 
address (i.e., the value associated with the AddressFriendlyName field of the product data 
structure) as the only entry. 

30 A method GetFirstProperty 922 is then invoked and, in a step 920, the 

GetFirstProperty method, examining the contaits of a property list pointer associated with 
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the product data structure of the selected product, locates the first property data structure 
in a linked list of property data structures referenced by the product data structure. 

Next, a method GetNextProperty 924 is repeatedly called in a step 926 to navigate 
the linked list of property data structures. In a step 928, a list box is created having an 
5 entry for each property name / property value pair encotmtered in navigating the linked 
list of property data structures. 

In a step 930, a GetPaymentFirstFriendlyName method 932 is invoked to examine 
the root pointer to the linked payment source structures and to retum the value of the 
Friendly Name of the first payment source structure. A Friendly Name, as discussed 

1 0 below, is simply a name like "Bob's Visa Card" which is conveniently used to designate a 
payment source. In the step 934, the GetPaymentNextFriendlyName method 936 is used 
to navigate the linked list of payment source structures, placing the Friendly Name of 
each in the drop-down box already created in the step 916. 

In a next step 938, a GetAddressFirstFriendlyName method 940 is invoked to 

1 5 examine the root pointer to the linked shipping address structures and to retum the value 
of the Friendly Name of the first shipping address stracture. A Friendly Name, as used 
with respect to an address, is a name like "the office" or "Dd>bie's house" which is 
conveniently used to designate a shipping address. In the step 942, the 
GetAddressNextPriendlyName method 944 is used to navigate the linked list of shipping 

20 address stmctures, placing the Friendly Name of each in the drop-down box already 
created in the step 918. 

Thus, a consumer can browse a list (displayed on the consumer's computer 102 
screen as a scrollable list box) of all properties and their corresponding values associated 
with the selected product and can modify the property values if desired. Also, the 

25 consumer can select fix>m either of the two drop-down boxes displayed on the consumer 
computer 102 to change the payment source to be used to purchase the product or to 
change the shipping address for delivery of the product if purchased. 

In a step 946, a choice box is displayed to the consumer offering the choices OK 
or CANCEL. If, in the step 948, it is detennined that the consumer selected CANCEL, 

30 then, in a step 950, the list box and the two drop-down boxes are cleared from the 
consumer computer and the steps of Figure 9 terminate. It however, in the step 948, the 
consumer selected OK, then, in a step 952, a SetltemProperty method 954 is invoked to 
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replace the values of the properties modified by the consumer, as well as to replace l£e 
Friendly Name for payment source or shipping address if either was changed by the 
consumer. The SEE ITEM DETAILS option is presrait on the commerce client user 
intoface as well as on Web documents. 

5 To manage payment source information, the present invention also allows a 

consumer to view and modify the contents of an electronic wallet. A Web document 
hosts (provides to a consumer) the option VIEW WALLET and includes embedded 
function-calling information which invokes wallet-related functions. It will be 
understood that the Web browser 120 generates a HTTP POST message directed to the 

10 local consumer computer 102, and that a port listener process receives the message and 
passes it to the commerce client 122 and also launches (executes) the commerce client if 
necessary. 

Figure 10 illustrates the stq>s performed in connection with viewing and 
manipulating payment source data. In a first step 1002, the consumer selects the VIEW 

15 WALLET option. Next, in a step 1004, the commerce client 122, having received the 
function-calling information fiiom the port listener, loads the wallet object. In a step 1006, 
the GetPaymentFirstFriendlyName method 1008 is invoked to examine a maintained root 
pointer (a pointer to the first in a linked list of payment source data structures) to 
determine the value of the Friendly Name associated with the first payment source data 

20 structure. This fust Friendly Name is used as the first entry in a list box. Next, in a step 
1010, the GetPaymentNextFriendlyName method 1012 is invoked to traverse the linked 
list of payment source data structures and place the Friendly Name associated with each 
as an entry in the list box. 

In the step 1014, a browsable list box is displayed to the consumer, listing all 

25 Friendly Names assigned to payment sources. In a next step 1016, options to ADD, 
EDIT, DELETE payment soimses are presented to the consumer, as is an option to 
MAKE PREFERRED (establish as the defeult) one of the payment sources. 

If, in the step 1016, the consumer selects the ADD payment source option, then, in 
a step 1018, a dialog box is displayed with blank or incomplete fields corresponding to 

30 payment source information. The fields are designed to elicit information such as credit 
card number, issuing bank, expiration date, name on card. Friendly Name, and billing 
address. The consumer can enter information corresponding to a credit card, debit card. 
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or any other cash substitute. Then, in a step 1020, the consumer filk in the fields and,lf 
the consumer desires to retain the entered information in the electronic wallet, the user is 
prompted to enter a password twice for verification in a step 1022. Whoi the passwords 
are typed correctly twice, then in a step 1024, the password is used to encrypt the entered 
S payment source data, and the encrypted data is stored in association with the Friendly 
Name entered by the consumer which is not encrypted. The consumer can then exit fiom 
viewing the wallet or continue with fiirther manipulations of payment source data. 

If, in the step 1016, the consumer selects EDIT payment source data, then upon 
selecting a Friendly Name corresponding to payment source data, the consumer, in a step 

10 1026 is prompted to enter a password. If the password is correct, it is used to decrypt the 
encrypted payment source information associated with the selected Friendly Name. In a 
step 1028, the decrypted payment source information is presented to the consumer in a 
dialog box. The data are broken into fields for consumer editing. 

In the step 1030, the consumer modifies the data fields. When the consumer is 

15 finished updating payment source information, the consumer, in a step 1032, is prompted 
to enter a password twice. This password may be difTerent fimm the password entered 
earlier to access the payment source data. When the password is successfiilly entered, the 
updated payment source data is encrypted and stored in association with the Friendly 
Name (which is not encrypted). Password protection at the consumer computer 102 level 

20 is an advantage of the present invention which ensures that only one person has access to 
credit card numbers and other financial information. 

In the step 1016, the consumer may elect to DELETE payment source data. Upon 
selecting from the list box of step 1014 a Friendly Name conresponding to payment 
source data to be deleted and also selecting the DELETE payment source option, the 

25 consumer is asked, in a step 1036, to confirm the deletion request. If the consumer 
confirms the deletion, then payment source data associated with the selected Friendly 
Name is removed fix)m the linked Ust of payment source data stmctures. It will be 
appreciated by those skilled in the ait that a password prompt can be added to the deletion 
steps to protect against undesired deletions. 

30 The step 1 01 6 also offers the option to MAKE PREFERRED one of the payment 

sources. Making a payment source preferred causes its Friendly Name to be associated 
by defeuh with product information that is added to the electronic shopping basket. 
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Generally, a preferred payment source would be an often used credit card account peih^s 
offering a very competitive interest rate or earning for the cardholder airlme fiequent flyer 
miles whenever money is spent If the consumer, in the step 1016, selects a Friendly 
Name from the list box of stq) 1014, and then selects MAKE PREFERRED, the Friendly 
5 Name selected becomes, in the step 1040, associated with the default payment source. 
One of ordinary skill will understand that a conjSrmation check could be added to the 
MAKE PREFERRED steps to avoid unintended replacements of a prior default payment 
source. When the consumer is finished viewing and manipulating payment source data, 
the user tCTminates the VIEW WALLET options and screen display by selecting an EXIT 

1 0 (or similarly labeled) button. 

Very similar to the marmer in which the present invention facihtates viewing and 
manipulating payment source data in the electronic wallet is the manner in which it 
permits consumers to view and manipulate shipping address data in the electronic address 
book. Figure 1 1 illustrates the steps in viewing or manipulating address book data. In a 

15 first step 1102, the consumer selects a VIEW ADDRESS BOOK option. In a next step 
1 104, the commerce client 122 loads the address book object. 

In a step 1 106, the GetAddressFirstFriendlyName method 1 108 uses a maintained 
root pointer (always points to the first of a linked list of shipping address data structures) 
to examine the first shipping address data structure and to return the associated Friendly 

20 Name. A Friendly Name for a shipping address might be, for example, "My Castle," or 
"Jill's Office." The Friendly Name associated with the first shipping address data 
structure is used as the first entry in a browsable list box. 

Next, in a step 1 1 10, the GetAddressNextFriendlyName method 1 11 2, is used to 
traverse the linked list of shipping address data structures and to include the Friendly 

25 Name associated with each structure in the list box created in stq> 1 106. The hst box is 
displayed to the consumer in step 11 14. A step 1116 presents options to the consumer to 
ADD, EDIT, DELETE shipping address data, as well as to MAKE PREFERRED a 
shipping address. 

If; in the step 1 1 16, the consumer elects to ADD shipping address data, then, in a 
30 step 1 11 8, a dialog box is displayed to the consumer containing blank or incomplete fields 
corresponding to shipping address data such as street address, city, state, country, zip 
code, name, and Friendly Name. In a next step 1 120, the consumer enters information 
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into the fields. When the consumer is satisfied that the infonnation is complete anH 
accurate, the consumer selects the OK button in the step 1 122, and the new shipping 
address is saved in association with the new Friendly Name entered. 

As with the electronic wallet, the consumer can also elect to EDIT data in the 
5 electronic address book. Because there is not as much need for security, there is no 
password access to or encrypting performed on the shipping address data. One skilled in 
the art will understand that password-protected access could be implemented in 
connection with the shipping address data as specified with respect to the payment source 
data. If the consumer elects to EDIT shipping address data, then, after selecting a 

10 Friendly Name firom the browsable list displayed in the step 1114, a dialog box is 
displayed in a step 1 124 presenting fielded data items corresponding to the existing data 
associated with the selected Friendly Name. In the step 1 126, the consumer modifies the 
existing shipping address data. When satisfied that the changes are complete, the 
consumer selects an OK button in a step 1 128 which saves the changed shipping address 

1 5 infonnation in association with the Friendly Name (which may have just been changed by 
the user). 

If, in the step 1 1 16, the consumer elects to DELETE shipping address data, then, 
after selecting a Friendly Name corresponding to a shipping address, the user is prompted 
in a step 1 130 to confirm the delete request. If the consumer confirms the delete request 
20 in the step 1 130, then in a step 1 132 the shipping address data is deleted along with the 
Friendly Name. 

If the option to MAKE PREFERRED a shipping address is selected in the step 
1116, then, in a step 1 134 the shipping address data associated with the selected Friendly 
Name is associated with the default shipping address. Thereafter, any products placed 

25 into the electronic shopping basket will acquire automatically, by default, an association 
with fhs new shipping address. One skilled in the art will appreciate that a confirmation 
step such as that in step 1130 with respect to deleting shipping address data could be 
added to safeguard against imintended modifications to the default shipping address. 
Note that both the VIEW WALLET and VIEW ADDRESS BOOK options are available 

30 fiom the commerce client user interface. 

With payment source information in the electronic wallet and shipping address 
infonnation in the electronic address book, the present invention enables a consumer to 
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purchase products in the electronic shopping basket. Wd) documents host a READY TO 
BUY option. 

Figure 12 illustrates the stq>s of purchasing a product. In a first step 1202, the 
consumer selects the READY TO BUY option. Next, in a step 1204, the shopping basket 
5 object is loaded. Then, in a step 1206, the GetFirstltem method 1208 is used to examine a 
maintained root pointer to the first merchant data structure and to then traverse and 
examine the linked list of product data structures associated with the first merchant and 
return the first located unpurchased product The Flag of each product data structure is 
examined to determine if the product is already purchased. If no unpurchased products 
10 are discovered in association with the firat merchant data structure, the GetFirstltem 
moves to the next merchant structure in the Unked list of merchants. The GetFirstltem 
method returns information (such as a pointer) identifying the first product structure 
associated with an unpurchased product encountered in its traversal of the merchant and 
product structures. 

15 In a next step 1210, the Gefl«JextItem method 1212 is used to complete the 

traversal of the machant and product structures, returning information identifying all 
product structures associated with unpurchased products. In a step 1214, a Ust of all 
unpurchased products is generated and is then sorted by merchant and by 
PaymentFriendlyName. Next, in a step 1216, the Ust of unpurchased products is 

20 displayed to the consumer, and the consumer is prompted to confirm the purchase request. 
If, in the step 1216, the consumer confirms the purchase, then the wallet object is loaded 
in a step 1218. Otherwise, the steps of Figure 12 are terminated and no purchase occiurs. 

With the unpurchased product items in the electronic shopping basket sorted by 
merchant (e.g. "L.L. Bean" or "Sears"), a step 1220 divides the product items into groups, 

25 one group per merchant. A first product group associated with a first merchant is 
designated for processing. A step 1222 then divides (or sorts) the first group into fiirther 
subgroups according to the value of the PaymentFriendlyName (e.g., "Gold Card" or 
"Mary's Amex"). Thus, different orders can be submitted to one merchant, but paid for 
using different payment sources. 

30 One having ordinary skill in the art will appreciate that a third subgrouping could 

be performed such as, for example, a subgrouping based on the value of 
AddressFriendlyName (e.g., "Grandma's House" or "Alaska Cabin"). Such an additional 
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subgrouping would conveniently support ordCTs which could be submitted to one 
merchant, cause payment fix}m different payment sources and assist the merchant in 
shipping products to different locations. Further, products paid for fipom the same 
payment source could conveniently be shipped to different addresses. 

S Associating a group of products for a single merchant that are to be purchased 

from a single payment source, a GSO (goods and services order) is submitted to the 
GenerateGSOPI method 1242 on the wallet object. In a step 1224, the GenerateGSOPI 
method 1242 extracts the stored and encrypted data (or blob) associated with the passed 
PaymentFriendlyName. In a next step, 1226, the consumer is prompted for a password to 

10 authorize payment from the payment source associated with the passed 
PaymentFriendlyName. If the password is incorrect, the purchase is not authorized and 
the next subgroup of products is identified whereupon step 1222 repeats. If, however, the 
password is correct, then the encrypted payment source data is decrypted in a step 1228, 
and a payment instruction is formed from the payment source information and the product 

15 information. The payment instruction contains data sufficient to allow a merchant to 
complete the order. In a next step, 1230, the payment instruction along with the product 
list is passed to an encryption DLL to be encrypted. The encryption DLL uses RSA 
encryption technology (a form of public/private key encryption) which is known. The 
present invention is not limited by encryption technology, and other forms of encryption 

20 could be used. The GenerateGSOPI method 1242 then passes the encrypted order to a 
step 1232 wherein the order is sent to a merchant's order URL (held as a field associated 
with a product data structure) as part of an HTTP POST message. Thus, the commerce 
client 122 is able to bypass the Web browser and transmit HTTP POST messages itself 

After transmitting an order, the commerce client 122 then updates the in memory 

25 structure for the respective merchant. Each merchant structure includes a reference 
pointer to a linked list of order stnictures. The commerce client 122 traverses the linked 
list of order structures, if any, to reach the final order stracture. The commerce client 122 
allocates memory for a new order structure, links the new stmcture to the list of order 
structures for the merchant, and then populates the new order structure with payment 

30 information, shipping address information, and a pointer to the product structure 
associated with the product ordered. An order tracking identifier ("OTT') field of the new 
order structure is left blank. One skilled in the art will appreciate that linked lists of 
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structures is merely one way of associating data items together, and that other methods 
such as relational databases can be used to accomplish a similar association. 

A merchant site receiving a product purchase order transmits an order 
confirmation message to a Web browser 120. The order confirmation message transmits 

5 an order tracking identifier ("OTT') to the Web browser 120. The Web browser 120 
displays the OTI on the screen of the user computer, along with a message which states, 
for example, "Thank you for your order. If there is any problem, please phone 1 800 123 
4567 and be prepared to refer to the following order tracking identifier." The OTI is also 
embedded in a MIME message of type x-ishopper which is passed by the Web browser 

10 120 to the commerce client 122. The commerce client 122 then copies the OTI to the 
blank OTI field of the order stracture, thus completing the storage of information related 
to the purchase. 

A step 1234 determines whether additional products for the current merchant 
remain to be purchased. If so, processing resumes at the step 1222, and, if not, processing 

1 5 resumes upon the next group of products fiom the next merchant at the step 1220. A step 
1236 determines whether all products for all merchants have been purchased. If not, then 
processing resumes with the step 1220. If all products have been purchased as 
determined by the step 1236, then the Flag field fijr every product in the electronic 
shopping basket is marked "purchased" (i.e., set equal to 1). Finally, in a step 1240, the 

20 steps comprising the VIEW SHOPPING BASKET option and the VIEW HISTORY 
option are invoked to force updates to memory structures and screen displays to avoid 
confiision as to whether any product was in fact purchased. 

An ORDER STATUS option is presented to a user by the commerce client 122 
after selection of the VIEW HISTORY option. Once a list of orders is generated and 

25 displayed to the user as described above, the user selects an order (preferably by 
positioning a mouse pointer over information associated with an order and clicking a 
mouse button). The user then selects the ORDER STATUS option. The commerce client 
then generates an HTTP POST message containing the order tracking identifier ("OTP'), 
and transmits the HTTP POST message to the order URL (uniquely identifying the 

30 Internet address of the selling merchant) associated with the product (or products) 
purchased. A merchant site receiving an HTTP POST message which includes an OTI 
determines tiie status of the order (e.g., "SHIPPED." "CANCELED," "WAITING FOR 
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INVENTORY," etc.). The merchant site transmits an HTML document to the WeB 
browser which includes the status mformation. The Web browser of the user computer 
displays the status information on the screen of the user computer. 

A consumer receives on-line assistance (or help) in usuig a computer-based 
5 shopping system by selecting a HELP option. In one embodiment, the HELP option is 
included in the HTML coding of a Web document and displayed to the user by a Web 
browser. Selecting the HELP option causes the Web browser 120 to access a HELP Web 
site. 

In another embodiment, the HELP option is displayed to the user by the user 

10 interfece of the commerce client 122. Selecting the HELP option in this embodiment 
causes the commerce client 122 to establish a TCP/IP communication link to another 
computer if such a link is not already established. The commerce client 122 transmits an 
HTTP POST message directly to a HELP Web site. The commerce cUent 122 causes the 
Web browser 120 to begin running on the user computer if it is not already nmning. 

15 In either embodiment of the HELP option, the Web browser displays help 

information included in documents served by a Web server of the HELP Web site. The 
help infomiation, for example, describes the use of the computer-based shopping system 
or the cause of errors encountered in operating the computer-based shopping system, 
offers tips, or illustrates feattires of the computer-based shopping system with pictures 

20 and diagrams. One skilled in the art will appreciate that on-line help could alternatively 
be made available to consumers via a hierarchically ordered (topics, subtopics, and sub- 
subtopics) collection of information residing on the consumer computer 102, 

A consumer conveniently accesses a merchant Web site 302 from which product 
information has been obtained by selecting the JUMP TO MERCHANT option. The user 

25 interface of the commerce client includes the JUMP TO MERCHANT option. By 
maintaining an association between a product name and a merchant Web site URL within 
the product data structure of every product, a computer-based shopping system locates a 
URL associated with the merchant selling a product by accessing the product data 
structure for ttie product The commerce client 122 generates an HTTP POST message 

30 accessing the merchant Web site associated with the product. The merchant Web site 
responds by transmitting an HTML document to the Web browser 120. Thus, the 
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consumer conveniently accesses the Web site from which information about a product 
was obtained. 

A consumer teraiinates a computer-based shopping system by selecting an EXIT 
button. The EXIT button causes the commerce client 122 to write linked in-memory data 
5 structures to a hard disk (other storage devices can suffice) in a manner which preserves 
the link relationships. The commoce client 122 then stops executing on the consumer 
computer 102. 

This invention may be embodied in other specific forms without departing from 
the essential characteristics as described herein. The embodiments described above are to 
10 be considered in all respects as illustrative only and not restrictive in any maimer. The 
scope of the invention is indicated by the following claims rather than by the foregoing 
description. Any and all changes which come within the meaning and range of 
equivalency of the claims are to be considered within their scope. 

In the claims which follow, alphabetic characters used to designate claim steps are 
1 5 provided for convenience of description only, and are not intended to imply any particular 
order for performing the steps. 
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WHAT IS CLAIMED: 

1 . A client architecture for conducting electronic conunerce over the Internet, 
comprising, on a computer-readable medium: 

a Web browser application configured to run on a computer; 
5 a commerce client application configured to run on the computer in conjunction 

with the Web browser application, the commerce client application including a callable 
function, said callable function comprising executable computer instructions stored on a 
computer storage medium accessible by the computer; 

an electronic shopping basket object configured to access and manipulate 
1 0 product information and merchant information stored on the computer storage 

medium, 

the access and manipulation initiated by executing the callable Amotion of the 
commerce client application; and 

a Web document which includes embedded function-calling infomiation that 
1 5 corresponds to the callable function of the commerce client application, the fimction- 
calling information embedded within the Web document such that a user can 
selectively initiate the execution of the callable function while viewing the Web 
document with the Web browser. 

20 2. A client architecture for conducting electronic commerce over the 

Internet, comprising, on a computer-readable medium: 

a Web browser q)plication configured to run on a computer; 
a commerce client qjplication configured to run on the computer in conjunction 
with the Web browser application, the conomerce client application including a callable 
25 fimction; 

an electronic shopping basket fiinction configured to store product information 
and merchant information to a computer storage medium accessible by the computer, said 
electronic shopping basket fimction comprising executable computer instructions stored 
on a computer storage mediimi accessible by the computer, the product information and 
30 merchant information retrieved Smm merchant Web sites over the Internet via the Web 
browser, the storing initiated by executing the callable function of the commerce client 
application; and 
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a Web document which includes embedded function-calling infoimation that 
corresponds to the callable function of the commerce client application, the function- 
calling information embedded within the Web document such that a user can 
selectively initiate the execution of the callable function while viewing the Web 
5 document with the Web browser. 

3. A client architecture for conducting electronic commerce over the 
Internet, comprising, on a computer-readable medium: 

a Web browser application configured to run on a computer; 
1 0 a commerce client application configured to run on the computer in conjunction 

with the Web browser application, the commerce client application including a callable 
function; 

an electronic shopping basket function configured to retrieve product information 
and merchant information fiom a computer storage medium accessible by the computer, 
1 5 said electronic shopping basket function comprising executable computer instructions 
stored on a computer storage medium accessible by the computer, the product information 
and merchant information obtained fiom merchant Web sites over the Internet via the 
Web browser, the retrieval initiated by executing the callable function of the commerce 
client application; and 

20 a Web document which includes embedded function-calling information that 

corresponds to the callable function of the commerce client application, the function- 
calling information embedded within the Web document such that a user can selectively 
initiate the execution of the callable fimction while viewing the Web document with the 
Web browser. 

25 

4. The client architecture according to Claim 1 , wherein the commerce client 
application includes a second callable function, and wherein the Web document includes 
embedded function-calling information that corresponds to the second callable function of 
the conmierce client ^plication, the execution of the second callable function selectively 

30 initiated by the user while viewing the Web document with the Web browser, the client 
architecture fiirther comprising, on the computer-readable medium: 
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an electronic wallet function configured to access and manipulate payment source 
infoimation stored on the computer storage medium, the access and manipulation of the 
payment source information initiated by executing the second callable function of the 
commerce client application. 

5 

5. The client architecture according to Claim 1 , wherein the commerce client 
application includes a second callable function, and wherein the Web document includes 
embedded function-calling information that corresponds to the second callable function of 
the commerce client application, the execution of the second callable function selectively 

1 0 initiated by the user while viewing the Web document with the Web browser, the client 
architecture further comprismg, on the computer-readable medium: 

an electronic address book object configured to access and manipulate shipping 
address information stored on the computer storage medium, the access and manipulation 
of the shipping address infomiation performed by executing the second callable fiinction 

1 5 of the commerce client application. 

6. A client architecture for purchasing products over the Internet, comprising, 
on a computer-readable medium: 

a commerce client application configured to mn on a computer, the commerce 
20 client application configured to transmit information to a World Wide Web site in 

accordance with World Wide Web protocols, the commerce client application configured 
to run in conjunction with a Web browser, the commerce client application including a 
product purchase function which combines product information, merchant information, 
and payment source information and transmits the combined information to a World 
25 Wide Web site, the product purchase function comprising executable computer 
instructions stored on the computer-readable medium. 

7. The client architecture according to Claim 6, further comprising, on the 
computer-readable medium: 

30 a Web browser application configured to run on the computer; and 

a Web document which includes embedded fimction-caUing information that 
corresponds to the product purchase fimction of the commerce cHent application, the 
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function-calling information embedded within the Web document such that the user can" 
selectively initiate the execution of the product purchase ftmction while viewing the Web 
document with the Web browser. 

5 8. The client architecture according to Claim 7, fiorther comprising, on the 

computer-readable medium: 

an electronic shopping basket object configured to access and manipulate product 
information and merchant information stored on the computer storage medium, the 
electronic shopping basket function ti:ansmitting product information and merchant 
1 0 information to the commerce client application during execution of the product purchase 
function of the commerce client application, the electronic shopping basket object 
comprising executable computer instructions stored on the computer-readable medium. 

9. The client architecture according to Claim 7, fimher comprising, on the 
IS computer readable medium: 

an electronic wallet object configured to access and manipulate payment source 
information stored on a computer storage medium accessible by the computer, tiie 
electronic wallet object transmitting payment source information to the commerce client 
application during execution of the product purchase fimction of the commerce client 
20 application, the electiwnic wallet object comprising executable computer instiuctions 
stored on the computQ--readable medium. 

10. A method for gathering product information over a distributed network, 
comprising: 

25 (a) sending a first hypertext document over the distiibuted network to a user 

computer, the first hypertext document comprising (i) a description of a first product, (ii) 
a usCT-selectable product gathering option, and (iii) fimction-calling information 
associated with the product gathering option; 

Cb) displaying the first hypertext document to a user via the user computer and 

30 monitoring user input for selection of Hie product gathering option; and 
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(c) responding to user selection of the product gathering option by calling an ~ 
executable function specified by the function-calling information, the fiinction storing the 
description of the first product to a local data storage area of the user computer. 

S 11. The method according to Claim 1 0 wherein step (a) comprises sending an 

HTML document over the distributed network fiom a Web server running on a merchant 
Web site to a Web browser running on the user computer, the Web server in a location 
remote to the Web browser. 

10 12. The method according to Claim 10 wherein step (c) further comprises 

passing at least a portion of the function-calling infonnation from a Web browser to a 
local process running on the user computer, the local process calling the function. 

13. The method according to Claim 10, further comprising the steps of: 

1 S (d) sending a second hypertext document over the distributed networic to the user 

computer, he second hypertext document comprising (i) a description of a second 
product, (ii) a second selectable product gathering option, and (iii) function-calling 
information associated with the second product gathering option; 

(e) displaying the second hypertext document to the user via the user computer 
20 and monitoring user input for selection of the second product gathering option; 

(f) responding to user selection of the second product gathering option by calling a 
second executable function, the second function storing the description of the second 
product to the local data storage area; 

(g) displaying a product comparison option to the user via the user computer and 
25 monitoring user input for selection of the product comparison option; and 

(h) responding to user selection of the product comparison option by retrieving 
firan the local storage area the description of the first product and the description of the 
second product, and by formatting the descriptions and displaying the descriptions to the 
user via the user computer. 

30 

14. A method for purchasing a plurality of products from a plurality of 
merchants over a distributed network, comprising the steps: 
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(a) storing on a computer storage medium a first network address corresponding 
to a first merchant and a second networic address corresponding to a second merchant, the 
computer storage medium accessible by a user computer; 

(b) storing on the computer storage medium a first product identifier uniquely 
S identifying a product of the first merchant and a second product identifier uniquely 

identifying a product of the second merchant; 

(c) storing on the computer storage medium payment source data, the payment 
source data representing a source of credit or a source of funds; 

(d) displaying a product purchase option to a user via the user computer and 
1 0 monitoring user input for selection of the product purchase option; 

(e) responding to selection of the product purchase option by combining the first 
product identifier with the payment source data to generate a first payment instruction, 
and by combining the second product idoitifier with the payment source data to generate 
a second payment instroction; 

1 5 (f) transmitting the first payment instruction Smm the user computer to the first 

network address over the distributed network; and 

(g) transmitting the second payment instruction fiom the user computer to the 
second network address over the distributed network. 

20 15. A method according to Claim 14 wherein step (f) comprises encrypting 

the first payment instruction and transmitting the encrypted first payment instruction to 
the first network address, and wherein step (g) comprises encrypting the second payment 
instruction and transmitting the encrypted second payment instruction to the second 
network address. 

25 

16. A method according to Claim 1 4 wherein the payment source data of step 
(c) is encrypted using an encryption password as a key, the encrypted payment source 
data not humanly readable, and wherein step (e) fiirther comprises prompting the user for 
entry of the encryption password and using the encryption password to decrypt the 
30 payment source data. 
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17. A method.for purchasing a plurality of products from a merchant over a " 
distributed network, comprising: 

(a) storing on a computer storage medium a network address corresponding to a 
merchant, the computer storage medium accessible to a user computer; 
5 (b) storing on the computer storage medium a product identifier uniquely 

identifying a product of the merchant; 

(c) storing on the storage medium a first quantity value representing a first 
quantity of the product and a second quantity value representing a second quantity of the 
product; 

1 0 (d) storing on the storage medium first and second encrypted payment source data, 

the first and second encrypted payment source data not humanly readable, the respective 
encryptions perfijrmed with user-entered first and second payment source passwords as 
encryption k^s; 

(e) displaying a product purchase option to a user on the user computer and 
1 5 monitoring user input for selection of the product purchase option; 

(f) responding to selection of the product purchase option by prompting the user 
for the first payment source password and the second payment source password; 

(g) monitoring user input for entry of the first and second payment source 
passwords; 

20 (h) decrypting the first encrypted payment source data using the first payment 

source password and decrypting the second encrypted payment source data using the 

second payment source password; 

(i) combining the product identifier, the first quantity value, and the first payment 

source data to generate a first payment instmction; 
25 (j) encrypting the first payment instruction to generate a first encrypted payment 

instruction; 

(k) transmitting the first encrypted payment instruction to the network address; 

(1) combining ttie product identifier, the second quantity value, and the second 
payment source data to generate a second payment instruction; 
30 (m) encrypting the second payment instruction to generate a second encrypted 

payment instmction; and 

(n) transmitting the second encrypted payment instmction to the network address. 
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18. A method in accordance with Claim 1 7 wherein the first payment 
instruction of step (i) is graerated by combining the product identifier, the first quantity 
value, the first payment source data, and a first shipping address, and wherein the second 

5 payment instruction of step (I) is generated by combining the product identifier, the 
second quantity value, the second payment source data, and a second shipping address, 
the method comprising the further step of: 

(o) storing on the computer storage medium a first shipping address and a second 
shipping address. 

10 

19. A method for using a Web browser to manage local data, the Web browser 
running on a user computer, the local data stored on a computer storage medium 
accessible by the user computer, the method comprising the steps of: 

(a) receiving with the Web browser an HTML document comprising a user- 

1 5 selectable view option and fiinction-calling information associated with the view option; 

(b) displaying the HTML document and the user-selectable view option to a user 
via the user computer; 

(c) monitoring user input for selection of the view option; and 

(d) responding to selection of the view option by calling a view fiinction specified 
20 in the function-calling information, the view function comprising executable computer 

instructions accessible by the computer, the view function accessing and formatting the 
local data and displaying the local data to the user. 

20. A method according to Claim 19 wherein the calUng of the view function 
25 of st^ (d) is performed by sending a message which includes at least a portion of the 

fimction-callmg infonnation firom the Web browser to a local Int^et address 
representing the user computer, a local port-monitoring process monitoring the local 
Intonet address and receiving the message, the local process using the function-calling 
information to make the fimction call. 

30 

21 . A method according to Claim 1 9 wherein the calling of the view function 
of step (d) is performed by sending a message which includes at least a portion of the 
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function-calling infonnation fix>m the Web browser to a local Internet address 
representing the user computer, a first local process monitoring the local Internet address 
and receiving the message, the first local process invoking a second local process if it is 
not already running, the first local process passing at least the fiinction-calling 
5 information to the second local process, the second local process using the fimction- 
calling information to call the view fimction. 

22. A method according to Claim 19 wherein step (d) comprises responding to 
selection of the view option by calling a view function represented in the function-calling 
1 0 information, the view function accessing and formatting the local data and displaying the 
local data to the user, and the view function also displaying an add option to the user, the 
method further comprising the steps of: 

(e) monitoring user input for selection of the add option; 

(f) responding to selection of the add option by prompting the user to enter 
1 5 additional local data; 

(g) monitoring user input for entry of additional local data; and 

(h) responding to entry of additional local data by storing the additional local data 
on the computer storage medium. 

20 23. A method according to Claim 1 9 wherein step (d) comprises responding to 

selection of the view option by calling a view function represented in the function-calling 
information, the view fimction accessing and formatting the local data and displaying the 
local data to the user, and the view function also displaying an edit option to the user, the 
method comprising the further steps: 

25 (e) monitoring user input for selection of the edit option; 

(f) responding to selection of the edit option by prompting the user to select 
displayed local data; 

(g) monitoring user input for selection of displayed local data; 

(h) responding to selection of displayed local data by presenting the selected local 
30 data to the user for editing via the user computer and by displaying a done option; 

(i) applying edit operations performed by the user via the user computer to the 
selected local data to generate edited local data; 
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(j) monitoring user input for selection of the done option; and 

(k) responding to selection of the done option by removing the selected local data 

from the computer storage medium and by storing the edited local data on the computer 

storage medium. 

5 

24. A method according to Claim 19 wherein step (d) comprises responding to 
selection of the view option by calling a view function represented in the function-caliing 
information, the view ftmction accessing and formatting the local data and displaying the 
local data to the user, and the view function also displaying a delete option to the user, the 

1 0 method comprising the fiirther steps: 

(e) monitoring user input for selection of the delete option; 

(f) responding to selection of the delete option by prompting the user to select 
displayed local data; 

(g) monitoring user input for selection of displayed local data; and 

1 5 (h) responding to selection of displayed local data by removing the selected local 

data from the computer storage medium. 

25. A method accordmg to Claim 19 wherein the local data represent at least 
one source of credit or source of fiinds. 

20 

26. A method according to Claim 19 wherein the local data represent at least 
one postal address. 

27. A method for tracking the status of a purchase order for a product over a 
25 distributed network, comprising: 

(a) storing on a computer storage medium a network address corresponding to a 
merchant, the computer storage medium accessible to a user computer; 

(b) transmitting to the network address data comprising a purchase order, the data 
including a product identifier, a quantity value, payment soince information, and shipping 

30 address information; 

(c) receiving an order tracking identifier corresponding with the purchase order; 

(d) storing on the computar storage medium the order tracking identifier; 
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(e) presenting an order status option to a user via the user computer; 

(f) monitoring user input for selection of the order status option; 

(g) responding to selection of the order status option by transmitting to the 
network address the order tracking identifier; 

5 (h) receiving order status information; and 

(I) displaying the order status information to the user via the user computer. 

28. A method in accordance with Claim 27 wherein the distributed network 
comprises the World Wide Web. 

10 

29. A method in accordance with Claim 28 wherein the network address of 
step (a) identifies a Web site of the World Wide Web. 

30. A method in accordance with Claim 29 wherein flie data transmitted in 
1 S step (b) is formatted as an HTIT POST message. 

31 . A method in accordance with Claim 28 wherein: 

step (c) comprises receiving via a Web browser a MIME message including an 
order tracking identifier corresponding with the purchase order, the MIME message 
20 passed to a local process; and 

step (d) comprises storing on the computer storage medium the order tracking 
identifier, the storing performed by instructions of the local process. 

32. A method in accordance with Claim 28 wherein the order status option of 
25 step (e) is included in an HTML-coded Web document, the order status option displayed 

to the user by a Web browser, the Web document including fimction-calling information 
associated with the order status option, and wherein: 

step (g) comprises responding to selection of the order status option by calling an 
order status Amotion rqn-esented in the fimction-calling information included in the Web 
30 document, transmitting to the network address an HTTP POST message including the 
order tracking identifier, the transmitting of tiie HTTP POST message performed by 
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instructions of the order status fiinction, the order status function comprising executable ^ 
computer instructions stored on the computer storage medium; 

step (h) comprises receiving with the Web browser a second HTML-coded Web 
document including order status information; and 
5 step (i) comprises displaying the order status information to the user via the Web 

browser. 

33 . A method for using a computer to access and display information, the 
method comprising the following steps: 

1 0 (a) establishing a communication link between the computer and a second 

computer using TCP/IP protocol; 

(b) running a local process on the computer, the local process displaying an 

information access option, the local process incapable of scanning an HTML file to 

generate a display on the computer screen; 
1 5 (c) monitoring user input for selection of the infonnation access option; 

(d) responding to selection of the infonnation access option by transmitting to the 
second computer an HTTP POST message including an infonnation access request, the 
transmission performed by instructions of the local process; 

(e) running a Web browser on the computer; 

20 (f) receiving an HTML file transmitted by the second computer, and 

(g) displaying via the Web browser, information included within the HTML file. 

34. A method according to Claim 33 wherein the information describes usage 
of the local process. 

25 

35. A method according to Claim 33 wherein the information describes the 
cause of an error in using or running the local process. 
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